Thread overview
[SAoC] New proposal: solve dependency hell for dub
Aug 10, 2019
Seb
Aug 11, 2019
Tiberiu Lepadatu
Aug 12, 2019
Seb
Aug 12, 2019
Seb
August 10, 2019
https://github.com/dlang/projects/issues/51

tl;dr:
- I just proposed a  SAoC project that might be of interest to people interested in the SAoC
- The project is about allowing multiple versions of a dependency in your dub project
- It is vital for many projects (in particular: moving Phobos to Dub)


A good intro into this topic:

https://stephencoakley.com/2019/04/24/how-rust-solved-dependency-hell
August 11, 2019
On Saturday, 10 August 2019 at 17:43:06 UTC, Seb wrote:
> https://github.com/dlang/projects/issues/51
>
> tl;dr:
> - I just proposed a  SAoC project that might be of interest to people interested in the SAoC
> - The project is about allowing multiple versions of a dependency in your dub project
> - It is vital for many projects (in particular: moving Phobos to Dub)
>
>
> A good intro into this topic:
>
> https://stephencoakley.com/2019/04/24/how-rust-solved-dependency-hell

Interesting project. I have some experience with D. Wrote some Rust. And I want to make a difference. Where do I sign up?
August 12, 2019
On Sunday, 11 August 2019 at 19:07:03 UTC, Tiberiu Lepadatu wrote:
> On Saturday, 10 August 2019 at 17:43:06 UTC, Seb wrote:
>> https://github.com/dlang/projects/issues/51
>>
>> tl;dr:
>> - I just proposed a  SAoC project that might be of interest to people interested in the SAoC
>> - The project is about allowing multiple versions of a dependency in your dub project
>> - It is vital for many projects (in particular: moving Phobos to Dub)
>>
>>
>> A good intro into this topic:
>>
>> https://stephencoakley.com/2019/04/24/how-rust-solved-dependency-hell
>
> Interesting project. I have some experience with D. Wrote some Rust. And I want to make a difference. Where do I sign up?

Awesome!
You can sign up here: https://dlang.org/blog/symmetry-autumn-of-code

If you have more questions regarding the project, probably the referenced GitHub issue is the best place to ask.
August 12, 2019
On Saturday, 10 August 2019 at 17:43:06 UTC, Seb wrote:
> https://github.com/dlang/projects/issues/51
>
> tl;dr:
> - I just proposed a  SAoC project that might be of interest to people interested in the SAoC
> - The project is about allowing multiple versions of a dependency in your dub project
> - It is vital for many projects (in particular: moving Phobos to Dub)

It may be a good idea to make sure that issues related to single-version dependencies are fixed first, e.g. <https://github.com/dlang/dub/issues/1732>, otherwise we risk a situation where multi-version dependencies are created unnecessarily.

BTW, why is this considered _vital_ for moving phobos to DUB?  I am not really convinced that Rust's approach is a solution -- it feels more like a dirty workaround that will have plenty of pain points of its own.
August 12, 2019
On Monday, 12 August 2019 at 10:34:40 UTC, Joseph Rushton Wakeling wrote:
> On Saturday, 10 August 2019 at 17:43:06 UTC, Seb wrote:
>> https://github.com/dlang/projects/issues/51
>>
>> tl;dr:
>> - I just proposed a  SAoC project that might be of interest to people interested in the SAoC
>> - The project is about allowing multiple versions of a dependency in your dub project
>> - It is vital for many projects (in particular: moving Phobos to Dub)
>
> It may be a good idea to make sure that issues related to single-version dependencies are fixed first, e.g. <https://github.com/dlang/dub/issues/1732>, otherwise we risk a situation where multi-version dependencies are created unnecessarily.
>
> BTW, why is this considered _vital_ for moving phobos to DUB?  I am not really convinced that Rust's approach is a solution -- it feels more like a dirty workaround that will have plenty of pain points of its own.

This was my personal opinion. The project description contains a general problem description.

Anyhow, you need to maintain compatibility with people using the current version. If we ever want to convert the standard library into a dub project, current code _must_ contain to work.

Sure, you can do 'import std2' etc, but I don't think this scales well and at least I don't want to write 'import std3_23'.

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 ;-)
August 13, 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?