www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [SAoC] New proposal: solve dependency hell for dub

reply Seb <seb wilzba.ch> writes:
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
Aug 10
next sibling parent reply Tiberiu Lepadatu <tiberiulepadatu14 gmail.com> writes:
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?
Aug 11
parent Seb <seb wilzba.ch> writes:
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.
Aug 11
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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.
Aug 12
parent reply Seb <seb wilzba.ch> writes:
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 ;-)
Aug 12
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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?
Aug 13