Dependency: Isolate SemVer version logic in its own struct

[Geod24]

Currently, Dependency is a mesh of logic, having evolved from a SemVer + branch only
version specification to semver, branch, path, repository.
In order to bring it under control, and attempt to have a smarter dependency matching,
we must first isolate the different ways we specify dependencies.

Code has been mostly moved. I assume the CI will yell at me, so I'll likely break this down.

[s-ludwig]

Same idea, but it got lost on the sideway: #1284

[Geod24]

@s-ludwig : Ideally I'd like to move this logic to a single module, namely https://github.com/dcarp/semver/ . I'll vendor it in DUB for the time being, but ideally I'd like to move it to dlang-community as many people would probably have similar needs.

Then the idea would be to make Dependency use SumType so that there is only one "provider" active at a time (path, repository, or version range).

[s-ludwig]

@s-ludwig : Ideally I'd like to move this logic to a single module, namely https://github.com/dcarp/semver/ . I'll vendor it in DUB for the time being, but ideally I'd like to move it to dlang-community as many people would probably have similar needs.

It would be really nice to switch to a self-hosted workflow where we can just use dub packages. There can still be a bootstrap script, and we could even include copies of external dependencies, instead of downloading them on demand, if someone deems that necessary. Although there should really be no need for that, considering that there is a binary included in every compiler distribution.

Then the idea would be to make Dependency use SumType so that there is only one "provider" active at a time (path, repository, or version range).

Sounds good.

[PetarKirov]

@Geod24 I suggest splitting dub into subpackages, similar to vibe-d, all hosted in this repo. A good example of other package managers whose repo is split like I envision is Yarn: https://github.com/yarnpkg/berry/tree/master/packages

[rikkimax]

Doing sub packagers would be a good idea indeed. Semver, git and repository management could all be candidates for this treatment.

…

On Fri, Jun 17, 2022, 18:15 Petar Kirov ***@***.***> wrote: @Geod24 <https://github.com/Geod24> I suggest splitting dub into subpackages, similar to vibe-d, all hosted in this repo. A good example of other package managers whose repo is split like I envision is Yarn: https://github.com/yarnpkg/berry/tree/master/packages — Reply to this email directly, view it on GitHub <#2271 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHSL4Z5VCEF6BOCXINGWRLVPQJZZANCNFSM5Y7FVNDA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Geod24]

It would be really nice to switch to a self-hosted workflow where we can just use dub packages.

I agree. I should restart work on #1972 (Two years, wow!).

There can still be a bootstrap script, and we could even include copies of external dependencies, instead of downloading them on demand, if someone deems that necessary. Although there should really be no need for that, considering that there is a binary included in every compiler distribution.

The only negative feedback to the above PR was asking for a bootstrap, so I think I'll pick the latest version and add a CI check to make sure we don't break it.

@Geod24 I suggest splitting dub into subpackages, similar to vibe-d, all hosted in this repo. A good example of other package managers whose repo is split like I envision is Yarn: https://github.com/yarnpkg/berry/tree/master/packages

I'm really not found of subpackages at the moment. They have quite a few quirks, and overlap with configurations. But I'll take a look.