On Monday, 15 April 2019 at 09:34:00 UTC, Anton Fediushin wrote:
> Compilation of dub-registry on a laptop with just 4Gb RAM takes ages and hangs up the whole system. A tiny edit in any diet template caused them all to be parsed over and over again.

Yeah, I think the code.dlang.org site is salvageable, but I am not a vibe.d and especially not a diet template fan. Such a pain.

> D is not the right tool for that particular job.

D is amazing for web stuff.

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.

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.

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.

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.

Kind regards
Andre

On Sunday, 14 April 2019 at 20:09:17 UTC, JN wrote:
> On Sunday, 14 April 2019 at 11:21:09 UTC, Andre Pany wrote:
>> [...]
>
> I think on the ecosystem side, dub is the #1 thing that ever came to D. I remember what life was before dub. First of all, there was no central repository, so it was hard to find a package you're interested in to begin with. Secondly, every package required additional steps to download dependencies, usually through a bash script. Then you had to roll a dice which build tool it expects, will it be bud, dsss, maybe makefiles, maybe something else? Oh, and if you were on Windows, you were screwed 99% of time, because the author loves bash and never tested it on non-POSIX platforms.
>
> [...]

I just want to mirror this exactly. I didn't really play with D much until DUB came along. Now is nearly always the language that I reach for when starting a new project.

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)

In the end it needs a dedicated programmer with a _principled_ vision, but I'm sure some money would find your way, maybe not much though.

I think recipe files (which format, we'll disagree on) and the registry are good and MUST be kept.

On Sunday, 14 April 2019 at 11:27:18 UTC, Jacob Shtokolov wrote:
> On Sunday, 14 April 2019 at 10:53:17 UTC, Seb wrote:
>> Hi all,
>>
>> The problem
>> -----------
>
> Hey guys, maybe this is an offtopic (which could sound heretical btw), but didn't you ever think about writing a package manager using some scripting languages like Python or JavaScript?
>
> The package manager is an infrastructure thing, so it not so critical as the rest of other tools.
>
> Maybe, a consideration of this idea would help to attract more people from the outside of the community, because there is a feeling that we're pretty much locked on the community itself.

I wonder what would possibly be gained from using Python or Javascript. If the goal is to have developers that are not current D users: (i) Why would they want to work on Dub? (ii) Why would we turn over the development of critical infrastructure to someone that doesn't know D and isn't interested in learning?

And then there's the marketing: D community rewrites critical infrastructure in an alternative language because D doesn't cut it. A better decision would be to shut down the project entirely.

On Sunday, 14 April 2019 at 20:09:17 UTC, JN wrote:
> I think on the ecosystem side, dub is the #1 thing that ever came to D. I remember what life was before dub.

+1

Life before DUB was hellish because it was impossible to have many projects, or rely on anithing external. Improving DUB (whatever the way) is a fantastic opportunity to improve D.

On 4/15/19 12:37 PM, 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).

To clarify, I'm mainly referring to the "package manager" aspect of DUB here. I'm less concerned with the "buildsystem" part simply because with a proper package manager, individual projects and even libraries will be free to use whatever buildsystem they want, even if that happens to be "dub build" (which *is* an entirely reasonable choice for many simpler projects...in large part because that's specifically the use-case it was primarily designed for.).

On Mon, Apr 15, 2019 at 06:56:24PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
[...]
> To clarify, I'm mainly referring to the "package manager" aspect of DUB here. I'm less concerned with the "buildsystem" part simply because with a proper package manager, individual projects and even libraries will be free to use whatever buildsystem they want, even if that happens to be "dub build" (which *is* an entirely reasonable choice for many simpler projects...in large part because that's specifically the use-case it was primarily designed for.).

Y'know, the idea just occurred to me: why even bind the package manager to the build system at all?  Why not make the build system one of the dependencies of the project?  So you could have library A that is written to be built using dub build, and library B that depends on 'make', say (where 'make' is some dub-ified description of make as a build system), and A depends on B.  So to build A, dub would fetch the necessary sources to build 'make', then use 'make' to build B, and then build A, and so forth.

This way, you can have multiple build systems coexisting peacefully with each other, without requiring the package manager to roll its own build system.  You could have library C depend on 'scons' and library D depend on 'gradle' or whatever, as long as there's a suitably dub-ified description of these build systems, dub could fetch and build them as dependencies and then use them to build whatever targets are needed. 'dub' itself (or maybe we should call it 'dub-build' or something) would be its own, standalone build module that projects could depend on by default.  So if you don't like dub's built-in build system, just override it to depend on 'make' or whatever your choice of build poison is.

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

If we were to pull this off, I might even consider using dub in a non-toy way. (Right now the only way I can get it to work sanely with my vibe.d project is to use the hack of an empty dub project whose sole purpose is to declare dub dependencies. It's ugly, and annoying.)


T

-- 
Без труда не выловишь и рыбку из пруда.

On 4/15/19 7:17 PM, H. S. Teoh wrote:
> On Mon, Apr 15, 2019 at 06:56:24PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> [...]
>> To clarify, I'm mainly referring to the "package manager" aspect of
>> DUB here. I'm less concerned with the "buildsystem" part simply
>> because with a proper package manager, individual projects and even
>> libraries will be free to use whatever buildsystem they want, even if
>> that happens to be "dub build" (which *is* an entirely reasonable
>> choice for many simpler projects...in large part because that's
>> specifically the use-case it was primarily designed for.).
> 
> Y'know, the idea just occurred to me: why even bind the package manager
> to the build system at all?  Why not make the build system one of the
> dependencies of the project?  So you could have library A that is
> written to be built using dub build, and library B that depends on
> 'make', say (where 'make' is some dub-ified description of make as a
> build system), and A depends on B.  So to build A, dub would fetch the
> necessary sources to build 'make', then use 'make' to build B, and then
> build A, and so forth.
> 

Yup, from the sound of it, I think we're on exactly the same page here. Basically, a package manager's config should need exactly three things from your project:

1. What dependencies.
2. The command(s) to (build, test, etc.)
3. Name(s)/Location(s) of the build's output.

Then, with that information, a package manager provides services such as (but not necessarily limited to):

1. A simple, standardized way for you and your users to obtain/build the dependencies.

2. A simple, standardized way for buildscripts/buildsystems to obtain the information needed to include the dependencies in their own build (such as -I... include directories, paths to the now-already-built lib/exec binaries, etc.)

From this, each project can naturally either just roll its own buildscripts, or depend on another package providing a builsystem.

Some of the *details* can be quite nontrivial...like dependency resolution algorithms, or designing the interactions between package manager and buildsystem to be simple, yet effective enough to suit all parties needs. But ultimately, it boils down conceptually to be very simple.

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.