Too many project is a nightmare to package.
Developper do not see that dub is a tool to help user to get some D lib as is done in ruby python or perl. But dub is not for packaging!

I am lazy to do this job and D packaging

good luck

Dear Jonathan,

It's sad to see you go, we desperately need any help we can get on the packaging front (for all those who don't know, Jonathan aka bioinfornatics has been maintaining several D-related packages in the official Fedora repositories).

However, I would argue that D libraries should not be packaged using the typical operating system package management facilities anyway, as those are very much tailored to mature C/C++ libraries. In the case of D, even if a given library tried to maintain a stable ABI, it would not succeed as the various compilers and different versions of the same compiler are not ABI-compatible (yet).

Together with the fact that one often wants to use several D compilers side by side (e.g. DMD for quick debug builds, LDC for optimized release versions, or the latest DMD version for a new project along with a slightly older one for some code that has not been updated yet), I think that dedicated language-specific tools like they are common with other newer programming languages are also the way to go for D.

What would be nice, however, is to have these D-specific tools such as DVM, dub, … available in the distro repositories, preconfigured to fit the customs of the given system. This way, users could just do "yum install dvm dub" (or whatever other tools) to get a fully working D environment.

David

On Sunday, 11 August 2013 at 17:15:52 UTC, David Nadlinger wrote:
> What would be nice, however, is to have these D-specific tools
> such as DVM, dub, … available in the distro repositories

Work in progress :)

I had release all rpm https://lists.fedoraproject.org/pipermail/devel/2013-August/187609.html

if no one take it they will go out of fedora.

I am lazy to explain that is not :
- a build system or dub
but
- a build system and dub

Firstly not everyone spent time to search their tool from cpan rvm pypi …
Secondly when you want the lib A who need bib B who need … you appreciate to have it in your repo
Third FHS rules and other was no create to annoyed dev…

If D dev should to install a compiller next a lib A dev a little get another lib … that is easier when that is into repo . That help to brings new users when all is into a repo

I had plan to package dub and vibe.d soon but now i stop all.

In brief That is a build system and dub

On Monday, 12 August 2013 at 07:13:11 UTC, bioinfornatics wrote:
> I had release all rpm https://lists.fedoraproject.org/pipermail/devel/2013-August/187609.html
>
> if no one take it they will go out of fedora.
>
> I am lazy to explain that is not :
> - a build system or dub
> but
> - a build system and dub
>
> Firstly not everyone spent time to search their tool from cpan rvm pypi …
> Secondly when you want the lib A who need bib B who need … you appreciate to have it in your repo
> Third FHS rules and other was no create to annoyed dev…
>
> If D dev should to install a compiller next a lib A dev a little get another lib … that is easier when that is into repo . That help to brings new users when all is into a repo
>

dub suits this purpose just fine. It's a build tool and a package manager. It can be used just like the various Linux package managers (dub install libname), but but it's even better in that you can skip that step entirely. List your project's dependencies in a package.json, and dub will automatically download and install them. Then they become available for every project you build with dub.

As a library maintainer, I find this much cleaner than relying on different people to maintain packages for different package managers. dubs configuration integrates with my git repo. The responsibility for registering with the dub registry is on me and I can keep it up to date with a simple config file. Most importantly, it makes it more likely that more users are on the same version and they can easily get the latest bug fixes when I update git without any extra effort on my part. On every platform that dub supports, not just Linuxen. rpms, deb files and whatnot often fall behind in the official package repositories and each one is only available to a certain subset of Linux users. dub is just a better option all around.

On 11/08/13 16:51, bioinfornatics wrote:
> Too many project is a nightmare to package.
> Developper do not see that dub is a tool to help user to get some D lib as is done in ruby python or perl. But dub is not for packaging!
> 
> I am lazy to do this job and D packaging
> 

It's very sad hear that you leaves this great work. I'd like to hear you have changed your decision. Let me ask you if your motives are only the exposed up or there are another ones?

Regards,
-- 
Jordi Sayol

On Sunday, 11 August 2013 at 17:15:52 UTC, David Nadlinger wrote:
> What would be nice, however, is to have these D-specific tools such as DVM, dub, … available in the distro repositories, preconfigured to fit the customs of the given system. This way, users could just do "yum install dvm dub" (or whatever other tools) to get a fully working D environment.

I don't know how it is for other distros, but the newest dmd and ldc version are available in the Archlinux's [community] repository while gdc and dub are available in the AUR, meaning you get a fully working D environment on Archlinux by doing
yaourt -S dmd dub
or
yaourt -S gdc dub
or
yaourt -S ldc dub
(you could use any pacman-wrapper other than yaourt, as well of course)

So far there isn't a dvm package (for Arch) that I can see, but if anyone where really interested he could do so, as the AUR anyone who registers an account may create (and maintain) new packages.


- Moritz

On Mon, 2013-08-12 at 09:58 +0200, Mike Parker wrote:
[…]
> dub suits this purpose just fine. It's a build tool and a package manager. It can be used just like the various Linux package managers (dub install libname), but but it's even better in that you can skip that step entirely. List your project's dependencies in a package.json, and dub will automatically download and install them. Then they become available for every project you build with dub.
> 
> As a library maintainer, I find this much cleaner than relying on different people to maintain packages for different package managers. dubs configuration integrates with my git repo. The responsibility for registering with the dub registry is on me and I can keep it up to date with a simple config file. Most importantly, it makes it more likely that more users are on the same version and they can easily get the latest bug fixes when I update git without any extra effort on my part. On every platform that dub supports, not just Linuxen. rpms, deb files and whatnot often fall behind in the official package repositories and each one is only available to a certain subset of Linux users. dub is just a better option all around.

Anecdotal experience indicates this musn't be an "or" situation.

From the Go experience, where this is furthest down the line in the native code arena (as far as I know): for Go having *both* operating system packaging *and* language specific packaging is the place to be.

The same goes for Python as well. Having platform packaging, and individual machine packaging is wonderful.

Platform packaging gives automated update, local packaging give the ability to get closer to the bleeding edge or stay behind the current platform packaging.

So I think D (dmd, gdc, ldc) and Phobos (for each of dmd, gdc and ldc),
as well as any other D infrastructure packages  need to be packaged for
Debian (which gives Ubuntu, Mint,…), Fedora (which gives RHEL, CentOS,…
), MacPorts, HomeBrew, <any-others-as-well>, and there needs to be a
(possibly dub-based) way of having a personal local installation of
things.

Currently GDC is in Debian, but I have to get DMD from a private Debian repository instead of the official one, and I build LDC myself because the Debian package is too old. This measn having to have three versions of all the libraries and packages because each compiler requires it's own. This sort of situation is well supported via platform packaging and currently seems unsupported completely via D-specific things – but I may be missing something.

Surely the issue that is arising here is that there isn't much communication and mutual support from the D community to the platform packaging ones for the various platforms. (Apart from GDC on Debian, which seems to be working fine now.)

So shouldn't OPs email be a call to get D and it's packages front and centre for all package-based platforms *as well as* getting a D-specific packaging system that knows how to deal with GitHub, BitBucket and Launchpad (plus others) in place and core to the community. Go's set up works, where is D's?


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 12 August 2013 11:38, Russel Winder <russel@winder.org.uk> wrote:
> On Mon, 2013-08-12 at 09:58 +0200, Mike Parker wrote:
> […]
>> dub suits this purpose just fine. It's a build tool and a package manager. It can be used just like the various Linux package managers (dub install libname), but but it's even better in that you can skip that step entirely. List your project's dependencies in a package.json, and dub will automatically download and install them. Then they become available for every project you build with dub.
>>
>> As a library maintainer, I find this much cleaner than relying on different people to maintain packages for different package managers. dubs configuration integrates with my git repo. The responsibility for registering with the dub registry is on me and I can keep it up to date with a simple config file. Most importantly, it makes it more likely that more users are on the same version and they can easily get the latest bug fixes when I update git without any extra effort on my part. On every platform that dub supports, not just Linuxen. rpms, deb files and whatnot often fall behind in the official package repositories and each one is only available to a certain subset of Linux users. dub is just a better option all around.
>
> Anecdotal experience indicates this musn't be an "or" situation.
>
> From the Go experience, where this is furthest down the line in the native code arena (as far as I know): for Go having *both* operating system packaging *and* language specific packaging is the place to be.
>
> The same goes for Python as well. Having platform packaging, and individual machine packaging is wonderful.
>
> Platform packaging gives automated update, local packaging give the ability to get closer to the bleeding edge or stay behind the current platform packaging.
>
> So I think D (dmd, gdc, ldc) and Phobos (for each of dmd, gdc and ldc),
> as well as any other D infrastructure packages  need to be packaged for
> Debian (which gives Ubuntu, Mint,…), Fedora (which gives RHEL, CentOS,…
> ), MacPorts, HomeBrew, <any-others-as-well>, and there needs to be a
> (possibly dub-based) way of having a personal local installation of
> things.
>
> Currently GDC is in Debian, but I have to get DMD from a private Debian repository instead of the official one, and I build LDC myself because the Debian package is too old. This measn having to have three versions of all the libraries and packages because each compiler requires it's own. This sort of situation is well supported via platform packaging and currently seems unsupported completely via D-specific things – but I may be missing something.
>

You can now get GDC from debian unstable if you want to risk it for a biscuit.  Not recommended for Debian stable, and look up apt-pinning for Debian testing releases.

Regards

Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Mon, 2013-08-12 at 11:41 +0100, Iain Buclaw wrote:
[…]
> 
> You can now get GDC from debian unstable if you want to risk it for a biscuit.  Not recommended for Debian stable, and look up apt-pinning for Debian testing releases.

I am already on Debian Unstable with GDC 4.8.1-8 :-)

I am though tending to favour LDC at the moment since I am building master/HEAD as the repository changes.

It seems that you have to work with one and only one D compiler — but that sort of makes sense really.
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder