On 11/12/2022 2:41 PM, Greggor wrote:
> 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 dub-registry abstracts that and provides zips for dub to download.

In an ideal world we can yes just download zips of sources and build. But we don't live in an ideal world. Builds are complicated. Sometimes you need to specify versions, run pre-build steps, use specific flags, exclude some sources for specific targets ext. Build managers hide all that from users so it is as simple as specifying a dependency and hit build.

But the biggest cost in dub is the searching of the registry for packages. ``--skip-registry=all`` is a massive speed up. Although there is work going into speeding it up it won't be quite as massive as caching the registry locally.

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.

On Sunday, 11 December 2022 at 03:16:24 UTC, max haughton wrote:

> 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.

This language is not helpful. It is used by people with a very narrow set of experiences that do not understand other use cases. That leads to terrible design decisions. I for one have no interest in build what you define to be a "real product".

On Sunday, 11 December 2022 at 03:49:53 UTC, bachmeier wrote:
> On Sunday, 11 December 2022 at 03:16:24 UTC, max haughton wrote:
>
>> 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.
>
> This language is not helpful. It is used by people with a very narrow set of experiences that do not understand other use cases. That leads to terrible design decisions. I for one have no interest in build what you define to be a "real product".

I understand them I just don't think its a useful model to build a package manager around. If you just want the package manager to be a glorified curl/git wrapper that fetches code with no other bells and whistles why not just use curl/git?

What dub should be able to do, wrt to locality is initialise and manage submodules for depdendencies automatically, as this makes some dependency-safety issues much easier to deal with – makes transitioning to internal forks/similar much more easy