[SAoC] New proposal: solve dependency hell for dub
Joseph Rushton Wakeling
joseph.wakeling at webdrake.net
Tue Aug 13 07:55:02 UTC 2019
On Monday, 12 August 2019 at 11:20:53 UTC, Seb wrote:
> This was my personal opinion.
It would be good if you could highlight opinions as such --
you're a figure of some authority and standing here, so if you
say something like "it's vital" it's good to be clear whether
this is something collectively agreed or not.
In particular, the arguments why this is a _requirement_ to move
phobos to DUB need to be really clearly laid out in the proposal.
> Also, as far as I am aware the Rust solution has been extremely
> successful for them and a vital part of their flourishing
> ecosystem. I'm open to better solutions though ;-)
Just because Rust has a flourishing ecosystem, does not
necessarily mean that we should just copy the surface details of
what they do ;-)
It really feels like this approach works around one set of
problems (which are mostly library maintenance problems) while
opening up a whole can of others (e.g. what happens when you get
multiple versions of libraries that expect to be the sole owner
of some important program component, such as a task scheduler?).
I don't object per se to the idea of customizable mangling (in
particular I like that the proposed solution is not
DUB-specific), but before rolling that into DUB as a dependency
resolution system, I think it would be really helpful to first
resolve the existing issues with single dependency resolution.
One particular thing I'd like to understand about the proposal:
how does the custom mangling interact with templates?
Suppose I have v1.x and v2.x of some project, and both versions
define (an identical) SomeTemplate, and that's used in my
project. Given how templates are incorporated into programs
(i.e. we can't pre-build it at the build-library stage, it's
instantiated only when the main program is built), how is it
decided which version's template to use, and hence which mangling
will be used?
More information about the Digitalmars-d
mailing list