On 16/04/2019 11:52 AM, Nick Sabalausky (Abscissa) wrote:
> I tried to argue in favor of an approach like this earlier on in DUB's development, but the author maintained that making a package ecosystem all work together requires all packages using the same buildsystem. I wasn't able to convince otherwise.

I can understand that argument. Regarding targets same compiler ext.

But I do agree that it would be the better design if they could all be worked out.

On 4/15/19 2:31 PM, Andre Pany wrote:
> 
> My assumption is, there are a lot of developers which uses dub without any issue and for them replacing Dub would be a major pain.
> 

We can't really say that replacing dub would be a pain without looking at what the replacement would be. Without that, we can only speculate.

On Mon, 2019-04-15 at 16:44 +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Monday, 15 April 2019 at 07:27:54 UTC, Russel Winder wrote:
> > I disagree. The lessons, particularly from Cargo/Rust, and Go is that "small language, small standard library, large pool of trivially accessible dependencies" is the way things are going just now.
> 
> You can still have that (and more of it, as we can get more library authors on board) if the systems are more compatible.
> 
> You can keep your `dub build` command if you must, but it should just forward to some user-defined system, which is able to get metadata like build target back out of dub.
> 
> 
> So, the dub executable does four (actually more!), conceptually independent tasks:
> 
> 1) get metadata about package
> 2) download package for use
> 3) full dependency resolution
> 4) build
> 
> And I want to decouple those as much as we can.

To be honest this is all implementation detail about which most users will not care. Most users really just want a single command with a CLI or a way of integrating with their IDE or editor.

So with Cargo and Rust you have the cargo command. How it is implemented really doesn't matter.

With Go there is the go command. How it is implemented really doesn't matter.

If Dub is the system for D then dub has a command line, how it is implemented under the hood really doesn't matter as long as it works. And currently it seems a bit of a mess. Especially compared to Cargo and Go.


-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Monday, 15 April 2019 at 18:31:01 UTC, Andre Pany wrote:
> On Monday, 15 April 2019 at 17:17:49 UTC, Atila Neves wrote:
>> On Monday, 15 April 2019 at 16:09:10 UTC, Andre Pany wrote:
>>> On Monday, 15 April 2019 at 13:34:21 UTC, Anton Fediushin wrote:
>>>> [...]
>>>
>>> Integration of dub with LDC is working fine. I created a tutorial (german) here:
>>>
>>> http://d-land.sepany.de/tutorials/einplatinenrechner/einstieg-in-die-raspberry-pi-entwicklung-mit-ldc/
>>>
>>> But yes, integration could be better.
>>>
>>> I use the shell commands to compile a git commit ID into the executable. It works like a charme.
>>
>> Try doing that cross platform between Windows and Linux.
>>
>>> Without specific examples it is hard to discuss wheter something works or not.
>>
>> My experience matches Anton's - as soon as you try to do anything non-trivial in "pure dub" it gets frustrating pretty quickly. I've given examples before.
>
> Actually I have a bat script for the windows release pipeline and a bash script for linux/Darwin pipeline.

Which is less than ideal.

> My assumption is, there are a lot of developers which uses dub without any issue and for them replacing Dub would be a major pain.

Of course! For trivial applications that want to use dependencies without hassle, it's great. But it doesn't scale.

> Also a lot of bugs were already solved in Dub in the recent month's. Bug fixes are just not listed in the D changelog.

The ones I filed are all open. And some aren't even filed yet AFAIK, such as the fact that dub.selections.json, as it exists now, is broken.

On Monday, 15 April 2019 at 19:52:10 UTC, Guillaume Piolat wrote:
> On Monday, 15 April 2019 at 16:37:38 UTC, Nick Sabalausky (Abscissa) wrote:
>> I've personally put a lot of effort into trying to fix DUB's problems in the past. Though I would be happy to be proven wrong, at this point, I'm all but convinced the problems with DUB are far too fundamental.
>>
>> I know this is the sort of proposal that makes people cringe, and often for good reason, but in this case, I really do think it would be quicker, easier, and produce a better result to simply re-design it from the ground up (while making sure to leverage the existing code.dlang.org ecosystem in some say), than to try to wrangle this 600lb gorilla into something it was never designed to be.
>>
>> I've long been hoping to take a stab at this myself, and I often find myself thinking through details of how it would work. I would, however, need help with the dependency-resolution algorithm (perhaps somebody could go into DUB and work to decouple its dep resolution algoritms from the rest DUB as much as possible - or at least document how to interface with it as a lib).
>
> I've tried paying MrSmith33 to write a DUB replacement for a while.
> I think the "incremental" camp is 80% right saying that a DUB rewrite is a pipe dream in large parts.
>
> However if you want to build on that small attempt, don't hesitate to pick what you like: https://gitlab.com/AuburnSounds/rub (coined "idub" for a pun)

I'll take a look. In the meanwhile I started this:

https://github.com/kaleidicassociates/bud

It uses dub as a library to make sure that it works just as dub does, but bypasses what it can. The idea is to completely separate these disparate tasks:

* Dependency version resolution (from dub.{sdl,json} -> dub.selections.json)
* Fetching dependencies that are not already in the file system (trivial after dub.selections.json has been generated)
* Extracting information from dub about source files, import paths, etc.
* Actually using the information from dub to build

In the future dub.selections.json will have to be fixed to have different entries per configuration, and possibly per platform as well. Fortunately there's a version field in the current format. I'm currently concentrating on assuming that dub.selections.json is generated and taking it from there.

On Monday, 15 April 2019 at 23:17:46 UTC, H. S. Teoh wrote:
> On Mon, Apr 15, 2019 at 06:56:24PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> [...]
>> [...]
>
> Y'know, the idea just occurred to me: why even bind the package manager to the build system at all?

They really shouldn't be. If anything, dub is a good example of why not.

> Why not make the build system one of the dependencies of the project?

That could work, as long as there's a sensible default one.

> For backward compatibility, 'dub-build' would be assumed if no build system is specified.

+1

On Tuesday, 16 April 2019 at 12:12:45 UTC, Atila Neves wrote:
> The idea is to completely separate these disparate tasks:
>
> * Dependency version resolution (from dub.{sdl,json} -> dub.selections.json)
> * Fetching dependencies that are not already in the file system (trivial after dub.selections.json has been generated)
> * Extracting information from dub about source files, import paths, etc.
> * Actually using the information from dub to build


It sounds like us dub-skeptics all actually agree on a surprising number of details.

If we go with a plan like this, we can get more authors on board and get dub some more serious buy-in.

On Tuesday, 16 April 2019 at 12:12:45 UTC, Atila Neves wrote:
>
> I'll take a look. In the meanwhile I started this:
>
> https://github.com/kaleidicassociates/bud
>
> It uses dub as a library to make sure that it works just as dub does, but bypasses what it can. The idea is to completely separate these disparate tasks:
>
> * Dependency version resolution (from dub.{sdl,json} -> dub.selections.json)
> * Fetching dependencies that are not already in the file system (trivial after dub.selections.json has been generated)
> * Extracting information from dub about source files, import paths, etc.
> * Actually using the information from dub to build
>

Won't complain about such good news!

dub.json and dub.selections.json must unify though, as dub.selections.json is not self-sufficient, what if they contradict themselves?


> In the future dub.selections.json will have to be fixed to have different entries per configuration, and possibly per platform as well. Fortunately there's a version field in the current format. I'm currently concentrating on assuming that dub.selections.json is generated and taking it from there.

I'm not really sure which are the original DUB assumtions.

I think our research concluded that solving dependencies for a particular platform+configuration is (in an idealized DUB) a fundamentally different operation than generating a proper dub.selections.json (for which you would have to find a super-set for "all conf"). The problem is that configurations/platform could appear and disappear alongside previous versions.


(For readers: this would lead the path to platform-based dependencies and configuration-based dependencies which are currently not doable, such as:

    "dependencies-linux": { "x11": "~>1.0" }
)

On Mon, Apr 15, 2019 at 08:59:26PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> On 4/15/19 2:31 PM, Andre Pany wrote:
> > 
> > My assumption is, there are a lot of developers which uses dub without any issue and for them replacing Dub would be a major pain.
> 
> We can't really say that replacing dub would be a pain without looking at what the replacement would be. Without that, we can only speculate.

As long as dub's current functionality is supported and remains the default behaviour, this is not an issue.  What's currently lacking isn't dub's default behaviour, it's the lack of support for changing the default behaviour.


T

-- 
Who told you to swim in Crocodile Lake without life insurance??

On Sunday, 14 April 2019 at 10:53:17 UTC, Seb wrote:
> Hi all,
> ...

I have a different proposal.

One of the goals of D is the interoperability with C/C++ and interoperability in general. Because of that I think it really make sens to not reinvent the wheel, but to have good support for an already existing tool.
Since a couple of months I'm using Bazel, and I like it. Not necessary the implementation (is big and Java), but the concepts behind it. So I'm already working right now on improving the D support [1]: adding more tests, supporting more compiler versions, etc.

So my plan is:
 - add tests: supporting d libraries, exectuables, tests and C++/D hybrid applications
 - add compiler version selection
 - ldc and gcc support
 - dub .json, .sdl -> bazel BUILD file converter (not foolproof). If necessary, manual intervention is acceptable.
 - add windows support
 - write a D starlark [2] implementation
 - rewrite bazel in D. Probably this will never happen, but maybe the subset sufficent to cover the dub functionality will be doable.

If somebody else is interested to join to this effort, please give me a sign.

Dragos

[1] https://github.com/bazelbuild/rules_d
[2] https://docs.bazel.build/versions/master/skylark/language.html