On Monday, 18 November 2019 at 19:44:46 UTC, Russel Winder wrote:
> On Mon, 2019-11-18 at 15:35 +0000, Joseph Rushton Wakeling via Digitalmars-d- announce wrote:
>> 
> […]
>> It is quite extraordinary how readily folks fall to arguing over what the config format should be, rather than what the app should actually be able to do. :-\
>
> Perhaps because writing the configuration files is a critical part of the usability of the tool.

IMO this is one of the most important parts of the first five minutes with the language. Someone has installed the compiler, and now they want to test it out. If they have a bad experience with Dub, they will not continue with the language. A package manager, including the choice of format, is something you have to get right. Rust understands this.

On Monday, 18 November 2019 at 19:54:38 UTC, Russel Winder wrote:
> It is so easy to make spelling errors in keys using hand-written JSON.

I don't understand why this would apply to JSON specifically. Whatever the language is, the config files will be hand-written; spelling errors are pretty universal, and anything we write is prone to mistakes to some extent

On Monday, 18 November 2019 at 23:08:13 UTC, Laurent Tréguier wrote:

> I don't understand why this would apply to JSON specifically. Whatever the language is, the config files will be hand-written; spelling errors are pretty universal, and anything we write is prone to mistakes to some extent

dud already tells you if you mistyped a key.

Adding new file formats is "trivial" with dud current code base.

This https://github.com/symmetryinvestments/dud/blob/master/pkgdescription/source/dud/pkgdescription/package.d is the data structure used to mirror the file content.

This https://github.com/symmetryinvestments/dud/blob/master/pkgdescription/source/dud/pkgdescription/json.d is the json reader.

Currently, I have no plans to add any other file format.
But PR's are always welcome.
The decision on json and sdl has been made a long time ago, for better
or for worse.
Please don't turn this thread into bike-shedding.
Additionally, dub/dud is already on the way to add cli functions to manipulate
the config file.
A look at adding dependencies with "dub add" already shows that.

On Monday, 18 November 2019 at 16:31:09 UTC, Nick Sabalausky (Abscissa) wrote:
> On 11/18/19 7:59 AM, Joseph Rushton Wakeling wrote:
>>        - I would imagine getting dependency resolution really right
>>          would be top of the list -- it would be good to aim to fix
>>          issues like https://github.com/dlang/dub/issues/1732
>
> As has been discussed elsewhere a few months ago, dependency resolution should be outsourced to an established SAT <https://en.wikipedia.org/wiki/Boolean_satisfiability_problem> solving lib, to avoid re-inventing a notoriously difficult wheel. This is what all the serious package managers have been moving towards, after invariably hitting problems (much like dub) trying to roll-their-own.

OT: By saying "all the __serious__" you effectively ended this part of the thread.
You basically say, that whatever I do, solve P=NP for instance, dud will
never be a __serious__ package manager because it does not use an
existing SAT solver.
That's just bad arguing.

The thing I want from dud, is to tell me what dependency chain let to conflicts
and this I find hard to extract from current SAT solvers.
Most I have worked with just told me: "This solution works" "NO"
Also the debug experience is not really great most of the time.
And I like a good debug experience.

I'm not saying I will or want to reinvent the wheel on dependency resolution,
but if there is a choice of Understandability + debugability vs. performance.
Performance will suffer.

On Tuesday, 19 November 2019 at 08:15:20 UTC, Robert Schadek wrote:
> Currently, I have no plans to add any other file format.
> But PR's are always welcome.
> The decision on json and sdl has been made a long time ago, for better
> or for worse.
> Please don't turn this thread into bike-shedding.

That wasn't my intention; sorry if I formulated my question badly. The reason I was asking is actually because I really don't see any one format having a huge advantage over the others; I'm fine with basically every format that has been listed in this thread so far.

On Monday, 18 November 2019 at 19:44:46 UTC, Russel Winder wrote:
> On Mon, 2019-11-18 at 15:35 +0000, Joseph Rushton Wakeling via Digitalmars-d- announce wrote:
>> 
> […]
>> It is quite extraordinary how readily folks fall to arguing over what the config format should be, rather than what the app should actually be able to do. :-\
>
> Perhaps because writing the configuration files is a critical part of the usability of the tool.

Fair.  My remark was maybe a little too intemperate :-)

I'm simply concerned that if we don't put enough scrutiny on the app features and behaviour, we run the risk of simply reproducing some of the problematic design decisions of the existing tool.

As an example -- try running `dub test --build=release`.  Intuition suggests that this is testing a release build.  But actually it strips out your unittests, because `--build=release` determines not only the optimization flags, but the complete set of DFLAGS used -- and `-unittest` isn't among them.

I ran `dub test && dub test --build=release` as a matter of habit for some time before discovering the latter wasn't actually testing anything.  And while I now know that I _can_ define a custom build to get what I want, that's clumsy and hard(er) to discover, and annoying to have to repeat for every project I create.

That's the kind of usability and design concern we really ought to be revisiting in any rewrite.

On Monday, 18 November 2019 at 16:31:09 UTC, Nick Sabalausky (Abscissa) wrote:
> As has been discussed elsewhere a few months ago, dependency resolution should be outsourced to an established SAT

I have no objections to that in principle, but I am not sure that will resolve the issue I posted: IIRC DUB's key problem is not so much how it resolves dependencies _per se_ but the fact that it includes dependency constraints that actually don't apply to a given build (e.g. constraints that derive from the testing requirements of dependencies).

On Monday, 18 November 2019 at 20:48:53 UTC, bachmeier wrote:
> IMO this is one of the most important parts of the first five minutes with the language. Someone has installed the compiler, and now they want to test it out. If they have a bad experience with Dub, they will not continue with the language. A package manager, including the choice of format, is something you have to get right. Rust understands this.

Fair point.  But that isn't something that has to be decided at the _start_ of a rewrite: better to focus on wanted behaviour, and then derive the ideal config format from that.

On 11/18/19 7:31 PM, Nick Sabalausky (Abscissa) wrote:
> On 11/18/19 7:59 AM, Joseph Rushton Wakeling wrote:
>>        - I would imagine getting dependency resolution really right
>>          would be top of the list -- it would be good to aim to fix
>>          issues like https://github.com/dlang/dub/issues/1732
> 
> As has been discussed elsewhere a few months ago, dependency resolution should be outsourced to an established SAT <https://en.wikipedia.org/wiki/Boolean_satisfiability_problem> solving lib, to avoid re-inventing a notoriously difficult wheel. This is what all the serious package managers have been moving towards, after invariably hitting problems (much like dub) trying to roll-their-own.
> 

does linear constraints solver fit here too?

On Mon, 2019-11-18 at 20:19 +0000, Tobias Pankrath via Digitalmars-d-announce wrote:
> On Monday, 18 November 2019 at 19:54:38 UTC, Russel Winder wrote:
> 
> > Probably yes. Though Cargo has taken many different decisions to Dub and mostly I think Cargo took better decisions.
> 
> Could you elaborate a bit, please? I am not familiar with Cargo though.

The single biggest difference for me just now is management of compilation products.

In an attempt to share compiled products between projects, Dub keeps all
downloaded package source and compilations products of that source in a
central location. This ends up with a very complicated, and more or less
unusable except by Dub, store of compilation products – especially as the easy
to get to compilation product has unknown compilation details. Also it assumes
you have infinite amounts of disc space.

Cargo keeps the downloaded package sources centrally, but leaves all compilation products in the project build area. This makes it easy to manage and the compilation details of the compilation products are easy to understand. OK you still have to manually manage the central repository but as it is source only, you get a much smaller growth to infinite disc space requirement.

As for smaller issues:

I prefer TOML over SDL as project specification notation (JSON is not an
option for me).

The convention over configuration rules for projects with multiple compilation products is nicer in Cargo compared to Dub.

Cargo is far more accepted in Rust circles than Dub is in D circles. The issue is not that this is true, but why is it true: is it just that D folk are still obsessed with Make, SCons, CMake, Meson, etc. where Rust folk have never even considered them.

D is still working with the ancient philosophy of the distributed standard library provides everything, cf. Python and "batteries included". Python has long ago had to give up on this and open its arms to PyPI based package distribution.  Go and Rust never went with the "batteries included" but put the infrastructure in place at the outset for supporting libraries from repositories – Rust/Cargo handles this far better than Go. The upshot is that the D package repository is still not really central to D code development. And using Git, Breezy, Mercurial, etc. repositories is just not as simple and straightforward as it is with Go and Rust/Cargo.

-- 
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