Re: Initial run of ./bin/dbupdate fails.

[bill-auger]

art - you sent that last message only to me - the mailing list
did not get it; but some points you made deserve exhibition


On Sat, 15 Oct 2022 20:48:35 -0700 (PDT) Art@TheTroyPress.com
wrote:
> Thanks, Bill, but I'm very close to giving up on this software. I just 
> wasted an entire day and more of my life struggling with -ahem- bullshit.

/me is on day 5 now - i had it fully packaged (aka: de-pipped
and installed) on day 4 - though it probably does not work yet,
because i have yet to package the javascript dependencies - i too
will give up (again), unless i reach the bottom of the
rabbit-hole soon


On Sat, 15 Oct 2022 20:48:35 -0700 (PDT) Art@TheTroyPress.com
wrote:
> In my not so humble opinion, sophisticated projects like Media Goblin 
> should NOT be written in Python for the very simple reason that it's a 
> nightmare for system managers. It's impossible to "package" reliably.

not impossible - but they definitely are more work than they are
worth; so very few of them ever get packaged for distros -
however, it is notable, that mediagobln is drastically better
than most "modern web apps", in that regard - unlike most,
complete/reproducible packaging is feasible - that is the only
reason i have attempted it

but that gripe applies to nearly all webby things - you are not
likely to find any which are easy to package - java-based
websites are usually worse; because they tend to download all of
their dependencies as binaries

ignoring the labor of packaging all of the dependencies, the
sheer number of dependencies also makes it a licensing
rabbit-hole - just to illustrate, i also looked at peertube, and
gave up hope on that one, immediately - it's terse dependency
manifest alone, is nearly 10,000 LOC, without a single mention
of any license

https://raw.githubusercontent.com/Chocobozzz/PeerTube/develop/yarn.lock

by contrast, mediagoblin has ~35 direct dependencies in my recipe
- python is quite well-packaged in our distro already; so i had
to package _only_ 15 of those - even that many dependencies is
excessive, compared to most other software - only a few
behemoths such as mozilla have nearly so many - but peertube
(like most webby things) had so many, that it was not worth my
time even to count the number of them

both programs are AGPL-licensed - yet although mediagoblin's
dependency graph is comparatively small, it is really something
of a mockery of the AGPL, to require users to fetch all those
dependencies from third-parties; if only because those
third-parties are not obligated to distribute any of them (as
these libs are permissively-licensed, almost exclusively) - the
GPL makes exemption from the "complete corresponding source"
requirement, only for what are vaguely considered to be essential
"system libraries"; but no reasonable amount of fuzziness would
place any python or javascript in that exempt set


On Sat, 15 Oct 2022 20:48:35 -0700 (PDT) Art@TheTroyPress.com
wrote:
> the "kids of today" 
> haven't bothered to pay attention to the lessons of the past. AND, Python 
> COULD deal with this and solve it with not too many changes. But they 
> obviously don't see the problem.

as bob marley said, "you cant blame the youth" - most web
software has been made that way for at least 15 years now

the reason for it, is because most web developers run windows or
macos; and those systems do not have proper package management -
so languages like python and ruby compensated for that deficiency
by establishing their own package management - ie: pip,
rubygems, npm, and the like, are actually an adequate solution to
a real problem, for most web developers - it is the only
dependency management tools available to them

those "third-party package managers" (TPPMs) are only so ugly
to developers who work on systems _with_ proper package
management; because TPPMs subvert proper system package
management, when it is present; and most offer no licensing
guidance - for most web developers, tools like pip are proper
"system" package management; because python/ruby/javascript is
"the system" - and the web browser is the machine, not any CPU