Let's make this part of 2.068:

https://issues.dlang.org/show_bug.cgi?id=14636

It's preapproved. Who would want to work on it?


Thanks,

Andrei

On 1 June 2015 at 09:01, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Let's make this part of 2.068:
>
> https://issues.dlang.org/show_bug.cgi?id=14636
>
> It's preapproved. Who would want to work on it?

Please declare a standard unix location for D 'includes'. Nobody
agrees where in the filesystem D files should be.
I use /usr/include/d2/ for my stuff (I saw it precedented a few times
before, but it doesn't seem that great), but I want a standard place
that stuff bundled by linux package managers can agree on.

As for dub, I'd use it if it worked like a package manager; dub get
libcurl-d libqt-d zlib-d libsdl2-d etc
I have no use for it as a build system, and therefore it's expression
of dependencies is no use to me. I just want something that works the
same way as '-dev' packages already work perfectly well in linux, that
is, they fetch headers and libs, and put them in a standard location
that all the tooling can find.

On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote:
> As for dub, I'd use it if it worked like a package manager; dub get
> libcurl-d libqt-d zlib-d libsdl2-d etc
> I have no use for it as a build system, and therefore it's expression
> of dependencies is no use to me. I just want something that works the
> same way as '-dev' packages already work perfectly well in linux, that
> is, they fetch headers and libs, and put them in a standard location
> that all the tooling can find.

I thought it does that.

If dub doesn't allow me to type one command to download and install all I need about a package, we need to add that pronto. I consider it a dealbreaker.


Andrei

On Monday, 1 June 2015 at 03:48:31 UTC, Manu wrote:
> On 1 June 2015 at 09:01, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> Let's make this part of 2.068:
>>
>> https://issues.dlang.org/show_bug.cgi?id=14636
>>
>> It's preapproved. Who would want to work on it?
>
> Please declare a standard unix location for D 'includes'. Nobody
> agrees where in the filesystem D files should be.
> I use /usr/include/d2/ for my stuff (I saw it precedented a few times
> before, but it doesn't seem that great), but I want a standard place
> that stuff bundled by linux package managers can agree on.
>
> As for dub, I'd use it if it worked like a package manager; dub get
> libcurl-d libqt-d zlib-d libsdl2-d etc
> I have no use for it as a build system, and therefore it's expression
> of dependencies is no use to me. I just want something that works the
> same way as '-dev' packages already work perfectly well in linux, that
> is, they fetch headers and libs, and put them in a standard location
> that all the tooling can find.

run dub fetch --help

On Monday, 1 June 2015 at 04:36:06 UTC, Andrei Alexandrescu wrote:
> On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote:
>> As for dub, I'd use it if it worked like a package manager; dub get
>> libcurl-d libqt-d zlib-d libsdl2-d etc
>> I have no use for it as a build system, and therefore it's expression
>> of dependencies is no use to me. I just want something that works the
>> same way as '-dev' packages already work perfectly well in linux, that
>> is, they fetch headers and libs, and put them in a standard location
>> that all the tooling can find.
>
> I thought it does that.
>
> If dub doesn't allow me to type one command to download and install all I need about a package, we need to add that pronto. I consider it a dealbreaker.
>
>
> Andrei

dub fetch does this already (though probably not quite what you are thinking of). You'd need to specify the paths manually because if it installed them to the global compiler paths we'd have dependency hell (what if 5 projects I have need 3 different versions of a library?). Also, you'd need root permissions.

That's not really how you use dub though. dub simply isn't a good fit for people who want it to be a system package manager. Its goals are different. If people want that they should work on getting libraries added to their preferred system's package registries.

With dub you specify the dependencies in the dub config file, not in some obscure section of an INSTALL file as a command the users need to run. You can checkout a project using dub and with a single command have dub download and build all the dependencies (and their dependencies) and then build your project against them.

dub is about making it easy for 99% of users. If you need your own build system then using dub just to download packages is overkill. Use git submodules or add something to do a download of your dependencies from github as part of your custom build system.

On 5/31/15 10:05 PM, Brad Anderson wrote:
> dub fetch does this already (though probably not quite what you are
> thinking of). You'd need to specify the paths manually because if it
> installed them to the global compiler paths we'd have dependency hell
> (what if 5 projects I have need 3 different versions of a library?).
> Also, you'd need root permissions.

Usability is key here. Installing stuff should really be as simple as pasting a command. That's how Flash won over Java applets etc. etc.

I installed a Python program the other day. I think it's rather obscure - it's called "lcinvestor". I got from knowing nothing about how to install Python stuff to having the application running in minutes.

The installation page at https://pypi.python.org/pypi/lcinvestor mentions at a point:

====
The easiest way to install is with pip:

sudo pip install lcinvestor
====

So I ran that. It didn't find pip. So I googled for it (first hit if you google for "pip"). Essentially I downloaded the script get-pip.py and then ran:

python get-pip.py

That worked nicely. Then I tried running pip again, it worked, and boom, I was up and running.

But wait, there's more. I then wanted to install lcinvestor on a machine I didn't have sudo access to. Sure enough, searching for things like ``pip without sudo'' took me to http://kazhack.org/?post/2014/12/12/pip-gem-install-without-sudo where I figured all I had to do:

pip install --local lcinvestor

Boom, I was set - the installation target was ~/.local/bin/. Sure enough that was in PATH and all so the program just worked.

That's the benchmark, folks. We need to get as good or better.

> That's not really how you use dub though. dub simply isn't a good fit
> for people who want it to be a system package manager. Its goals are
> different. If people want that they should work on getting libraries
> added to their preferred system's package registries.

Then we need a different program than dub. "dip" :o).

> With dub you specify the dependencies in the dub config file, not in
> some obscure section of an INSTALL file as a command the users need to
> run. You can checkout a project using dub and with a single command have
> dub download and build all the dependencies (and their dependencies) and
> then build your project against them.

That seems reasonable.

> dub is about making it easy for 99% of users. If you need your own build
> system then using dub just to download packages is overkill. Use git
> submodules or add something to do a download of your dependencies from
> github as part of your custom build system.

That seems reasonable, too.

So are we there yet?


Andrei

On 1 June 2015 at 14:57, weaselcat via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 1 June 2015 at 03:48:31 UTC, Manu wrote:
>>
>> On 1 June 2015 at 09:01, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> Let's make this part of 2.068:
>>>
>>> https://issues.dlang.org/show_bug.cgi?id=14636
>>>
>>> It's preapproved. Who would want to work on it?
>>
>>
>> Please declare a standard unix location for D 'includes'. Nobody
>> agrees where in the filesystem D files should be.
>> I use /usr/include/d2/ for my stuff (I saw it precedented a few times
>> before, but it doesn't seem that great), but I want a standard place
>> that stuff bundled by linux package managers can agree on.
>>
>> As for dub, I'd use it if it worked like a package manager; dub get
>> libcurl-d libqt-d zlib-d libsdl2-d etc
>> I have no use for it as a build system, and therefore it's expression
>> of dependencies is no use to me. I just want something that works the
>> same way as '-dev' packages already work perfectly well in linux, that
>> is, they fetch headers and libs, and put them in a standard location
>> that all the tooling can find.
>
>
> run dub fetch --help

Interesting. I'm amazed this never came up before in discussion...
I've talked about this so many times.
So, DMD/LDC/GDC know where to look to find these packages? What
happens if the package includes a binary lib?

That that, I still want someone to declare an official path for D 'includes' in the *nix filesystem, so D lib packages have somewhere to install...

On Monday, 1 June 2015 at 05:27:00 UTC, Manu wrote:
> On 1 June 2015 at 14:57, weaselcat via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Monday, 1 June 2015 at 03:48:31 UTC, Manu wrote:
>>>
>>> On 1 June 2015 at 09:01, Andrei Alexandrescu via Digitalmars-d
>>> <digitalmars-d@puremagic.com> wrote:
>>>>
>>>> Let's make this part of 2.068:
>>>>
>>>> https://issues.dlang.org/show_bug.cgi?id=14636
>>>>
>>>> It's preapproved. Who would want to work on it?
>>>
>>>
>>> Please declare a standard unix location for D 'includes'. Nobody
>>> agrees where in the filesystem D files should be.
>>> I use /usr/include/d2/ for my stuff (I saw it precedented a few times
>>> before, but it doesn't seem that great), but I want a standard place
>>> that stuff bundled by linux package managers can agree on.
>>>
>>> As for dub, I'd use it if it worked like a package manager; dub get
>>> libcurl-d libqt-d zlib-d libsdl2-d etc
>>> I have no use for it as a build system, and therefore it's expression
>>> of dependencies is no use to me. I just want something that works the
>>> same way as '-dev' packages already work perfectly well in linux, that
>>> is, they fetch headers and libs, and put them in a standard location
>>> that all the tooling can find.
>>
>>
>> run dub fetch --help
>
> Interesting. I'm amazed this never came up before in discussion...
> I've talked about this so many times.
> So, DMD/LDC/GDC know where to look to find these packages? What
> happens if the package includes a binary lib?
dub uses git to manage packages, it keeps the list of D packages on http://code.dlang.org/

the help is a bit unintuitive, it just gives a brief overview with dub --help, you have to issue a subcommand to get the help about it.

>
> That that, I still want someone to declare an official path for D
> 'includes' in the *nix filesystem, so D lib packages have somewhere to
> install...

the problem is that XDG didn't really define a standard for user-level libraries and binaries, so it's a huge mess.

Dub is actually violating part of the XDG standard as is because it defaults to ~/.dub
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

On Monday, 1 June 2015 at 05:27:00 UTC, Manu wrote:
> On 1 June 2015 at 14:57, weaselcat via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Monday, 1 June 2015 at 03:48:31 UTC, Manu wrote:
>>>
>>> On 1 June 2015 at 09:01, Andrei Alexandrescu via Digitalmars-d
>>> <digitalmars-d@puremagic.com> wrote:
>>>>
>>>> Let's make this part of 2.068:
>>>>
>>>> https://issues.dlang.org/show_bug.cgi?id=14636
>>>>
>>>> It's preapproved. Who would want to work on it?
>>>
>>>
>>> Please declare a standard unix location for D 'includes'. Nobody
>>> agrees where in the filesystem D files should be.
>>> I use /usr/include/d2/ for my stuff (I saw it precedented a few times
>>> before, but it doesn't seem that great), but I want a standard place
>>> that stuff bundled by linux package managers can agree on.
>>>
>>> As for dub, I'd use it if it worked like a package manager; dub get
>>> libcurl-d libqt-d zlib-d libsdl2-d etc
>>> I have no use for it as a build system, and therefore it's expression
>>> of dependencies is no use to me. I just want something that works the
>>> same way as '-dev' packages already work perfectly well in linux, that
>>> is, they fetch headers and libs, and put them in a standard location
>>> that all the tooling can find.
>>
>>
>> run dub fetch --help
>
> Interesting. I'm amazed this never came up before in discussion...
> I've talked about this so many times.
> So, DMD/LDC/GDC know where to look to find these packages? What
> happens if the package includes a binary lib?

No. But dub knows where the packages are, and the usual way to use it is to use dub to compile. If not, there's always `dub describe`, which will tell you exactly where the dependencies are.

Atila

> That that, I still want someone to declare an official path for D
> 'includes' in the *nix filesystem, so D lib packages have somewhere to
> install...

On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 1 June 2015 at 04:36:06 UTC, Andrei Alexandrescu wrote:
>>
>> On 5/31/15 8:48 PM, Manu via Digitalmars-d wrote:
>>>
>>> As for dub, I'd use it if it worked like a package manager; dub get
>>> libcurl-d libqt-d zlib-d libsdl2-d etc
>>> I have no use for it as a build system, and therefore it's expression
>>> of dependencies is no use to me. I just want something that works the
>>> same way as '-dev' packages already work perfectly well in linux, that
>>> is, they fetch headers and libs, and put them in a standard location
>>> that all the tooling can find.
>>
>>
>> I thought it does that.
>>
>> If dub doesn't allow me to type one command to download and install all I need about a package, we need to add that pronto. I consider it a dealbreaker.
>>
>>
>> Andrei
>
>
> dub fetch does this already (though probably not quite what you are thinking of). You'd need to specify the paths manually because if it installed them to the global compiler paths we'd have dependency hell (what if 5 projects I have need 3 different versions of a library?). Also, you'd need root permissions.

Yeah, but regardless, that's what I want.
I don't have version hell with C libs distributed this way...? Is this
a problem that people are specifically trying to avoid?


> That's not really how you use dub though. dub simply isn't a good fit for people who want it to be a system package manager. Its goals are different. If people want that they should work on getting libraries added to their preferred system's package registries.

Right, so, someone decide a path, we'll write it on dlang.org, and then everyone will agree and fall in line :)


> With dub you specify the dependencies in the dub config file, not in some obscure section of an INSTALL file as a command the users need to run. You can checkout a project using dub and with a single command have dub download and build all the dependencies (and their dependencies) and then build your project against them.

I get it, it sounds great... if your app suits the model.
I have no D-only projects, all my programs combine many languages and
ecosystems.
There are also existing build systems that are well established that I
prefer to use, integrate with IDE's, etc.

I don't mind if people use dub, but I just want a way to fetch libs that the compilers will then find automatically.


> dub is about making it easy for 99% of users. If you need your own build system then using dub just to download packages is overkill. Use git submodules or add something to do a download of your dependencies from github as part of your custom build system.

Point is, I don't have to do this with C. I just install the dev
package, once, and I'm done. Package manager distributes updates
automatically, everything it exactly how I want it.
It's just not a wheel I have any interest in reinventing.

I'm not trying to heckle. I just want someone to declare the word on
where in the filesystem we put .d files, parallel to c includes.
I think the single most important thing is for bindings against C libs
that are installed by common -dev packages, it would be easiest if the
bindings were fetched and installed the same way as the libs they
refer to.