DUB 2.0: Should we get started ?

[Geod24]

There has been a few talks about DUB 2.0 in the past. Since DUB is a library that follow SemVer, we can't just go and change the public API, however we don't have much checks for it either.

What I would suggest as a good stepping stone for DUB 2.0:

• Remove deprecated code (e.g. Remove dub.packagesupplier #1827)
• See what can be cleared up (e.g. Remove buildRequirements: relaxProperties #2068)
• Make DUB self-hosted ([RFC] Make dub self hosted #1972)
• See what breaking changes we want in;
• Consider re-organizing the source code in a more logical way (e.g. the way packagesuppliers was created);

IMO that's the absolute minimum. It might sound too little for a major release, but we haven't bumped the major release for a year, so I'd rather have a bump now with few changes than in a year with the same amount of changes.

CC @PetarKirov @s-ludwig

[jacob-carlborg]

Perhaps: #1683. This could easily be fixed without breaking anything with a new environment variable. But it would be nicer to not have two environment variables for the same thing.

[jacob-carlborg]

A couple of more suggestions:

• Remove local packages
• Remove overrides
• Allow uploading packages that are not tied to a Git repository
• Switch recipe format to YAML

[Geod24]

It would be good to have such an issue so we can discuss the rationale. Also note that those could already be deprecated without a breaking change.

[Geod24]

Ping @jacob-carlborg : That's something I'd be interested to look into, but I'd like to discuss the rationale.

[jacob-carlborg]

The reason for these features seems to be to use packages which are not published on the Dub registry. I think there are better alternatives available now, like path based and git based dependencies. If you register a local package, if will use the local package for all projects that has this as a dependency, which can be highly confusing.

I have not verified this, but I think Dub is doing unnecessary work because of these features. But perhaps this can be improved upon. For example, you create a new Dub project with no dependencies, build it with with verbose output enabled: dub build --vverbose. This the output you get:

Using dub registry url 'https://code.dlang.org/'
Refreshing local packages (refresh existing: true)...
Looking for local package map at /var/lib/dub/packages/local-packages.json
Looking for local package map at ~/.dub/packages/local-packages.json
Looking for local package map at ~/tmp/foo/.dub/packages/local-packages.json
iterating dir ~/.dub/packages/
...
Note: Failed to determine version of package foo at .. Assuming ~master.
Refreshing local packages (refresh existing: false)...
Looking for local package map at /var/lib/dub/packages/local-packages.json
Looking for local package map at ~/.dub/packages/local-packages.json
Looking for local package map at ~/tmp/foo/.dub/packages/local-packages.json
iterating dir ~/.dub/packages/
...
Collecting dependencies for foo
Refreshing local packages (refresh existing: false)...
Looking for local package map at /var/lib/dub/packages/local-packages.json
Looking for local package map at ~/.dub/packages/local-packages.json
Looking for local package map at ~/tmp/foo/.dub/packages/local-packages.json
iterating dir ~/.dub/packages/
...

I replaced all output of the local packages with ... to reduce the amount of text. Why on earth would it scan all these directories and files and why three times? The package doesn't even have any dependencies.

Dub has quite a bit of overhead compared to just invoking the compiler. It would be nice to reduce that as much as possible.

[ghost]

Switch recipe format to YAML

If I may, what is the reasoning behind this with SDL being a supported format? The latter is clean and simple, and it ostensibly doesn't have as many corner cases as YAML.

[Geod24]

SDL has very little tool support and isn't well known. It also hasn't gained traction outside of D.

[Geod24]

Ping @s-ludwig

[jmh530]

What about splitting dub into two projects? One for managing dependencies and one for building given dependencies?

[Geod24]

I started this discussion 20 months ago. I think if we've gone with it, our life would be a little bit better now 🙃
Nonetheless, I've recently made quite a lot of progress on items that had a lot of technical debt (e.g. Dependency handling).
I'll go forward without breaking code for as long as possible, but I've been introducing so many deprecations that we most likely will need to do this by EOY.

[MrcSnm]

@Geod24

FYI, I've done redub. Which is completely usable for my projects and much others. It has changed some things from what dub currently does. But to be fair, in my POV, working with how it currently is, it is completely masochism.

dub is a great concept, but in its project maintenance, it is way harder than how redub was designed. If you want to take a look: https://github.com/MrcSnm/redub

It also supports to be used as a library. The code is not stateful, it is almost completely functional, which means: no hidden state. I don't have a single usage of polymorphism which makes it easier to understand. It didn't try to be smart. It is literally what dub brings: simplicity.

I must say, however, that the direction I'm taking this project is first to take out some of what dub does. I do not intend to implement features that I don't use.

That being said, at least feel free to try it out, including as a library or not, try reading the code and say your feelings.

redub did not implement anything related to package management side. If you're able to cut it off in a separate package from dub, I may as well as just reuse it. (I've also dropped of dub.selections.json).