What Julia Does Right

[max haughton]

On Sunday, 11 December 2022 at 01:41:21 UTC, Greggor wrote:
> On Saturday, 10 December 2022 at 14:24:53 UTC, max haughton 
> wrote:
>> [...]
>
> I'm not using git for version control, I'm using fossil so I'm 
> not sure if this is applicable to me.
>
> Its not just about building without an internet connection. 
> It's more of a measuring stick I use. There are several reasons 
> I do it, mainly its "trauma" from the JS/NPM ecosystem.
>
> the two stories I'm sharing may not seem relevant, but they are 
> to the point I'm making.
> Maybe I'm a goof & live in a bubble, but I'd like to argue that 
> D currently has a better dependence experience then most 
> ""nicer"" systems based on some anecdotal evidence :^)
>
> JS:
>>[...]
>
> Python:
>>[...]
>
> Dlang:
>>[...]
>
> My goal here is not to appear like a luddite or to tell others 
> to be ones, I think having nice tooling is a good goal, I'd 
> love to have a good package manager for D with a quality 
> ecosystem.
>
> Here is how I would go about this:
> 	* A dependency should always be just a tar/zip file with src 
> code in it.
> 	* The dependency (tar/zip)s should always be stored in the 
> project directory & not in some system or user folder.
> 	* No use of symlinks
> 	* To help discourage NPM insanity, Build in a ""Bloat"" 
> measuring tool, how many total dependencies are you using? how 
> many KLOC is it?
> 	* https://code.dlang.org should have a link for the manual 
> direct download for the src zip for all versions.
>
> 	Github, Gitea instances & Fossil all have a way of providing a 
> zip file for releases, src zips are already a near universal 
> method of publishing code. So this theoretical package manager 
> can be really fast and light, its basically an over gloried 
> text search & download tool.

The way to use a git submodule with dub is just that you can 
point it at a path, it doesn't care where the path came from as 
long as there's a dub repo there.

Fetching code and putting it somewhere is relatively trivial, 
it's not why people use package managers - dealing with a 
ratsnest of dependencies and resolving which versions satisfy all 
of them (if at all) is why eventually you need a "real" package 
manager - or rather package managers end up looking the way they 
do.

Also saving dependencies in a user folder is tempting and 
sometimes correct but if you have to build a real product you 
typically have either subprojects or entirely separate projects 
with the same dependencies in them — if these are all stored in 
their own local folder then you end up fetching and building 
things multiple times (dub suffered from the latter until very 
recently IIRC). You could have a single per-product build dir but 
at that point you've lost the locality and might as well just 
have it in /home/ or wherever.