February 22, 2013
Am 21.02.2013 22:06, schrieb Graham Fawcett:
> On Sunday, 17 February 2013 at 07:23:22 UTC, Sönke Ludwig wrote:
>>> You might want to list all the dependencies needed for dub or distribute them in a zip.
>>>
>>
>> They are in the .zip now and I listed the dependencies on the download page. Sorry, the distribution stuff is still very much ad-hoc ATM. I'll make some installers once the build process is automated.
>>
>>> Ah I didn't spot the download link http://registry.vibed.org/download
>>>
>>> I guess this could be made more visible by adding a link to the download page from the github repository, and maybe putting the { * Using DUB * Download * Publishing packages * Helping developme } section at the top instead of the bottom.
>>
>> There now is a link on the github page + a note for non-Windows that libevent/libssl are needed. I also added a short sentence how to build by hand. The dependencies will also likely change to just libcurl at some point with a make file or something to make bootstrapping as simple as possible.
> 
> Personally, I think that libcurl-only dependency is an important goal. Dub's third-party dependencies are far too "modern." For example, I have an older Ubuntu instance I use for testing (10.10), where libevent 2.x simply isn't available (can't run your binary, and can't compile your source).
> 
> For Vibe, these may be acceptable requirements, but not for a general packaging tool.
> 
> I would hope that a future version of Dub wouldn't have any dependencies on Vibe, either. That's an odd bootstrapping arrangement.
> 
> Best,
> Graham

Fully agree, this planned as the next step (since it was a part of vibe.d in the beginning, using that just was the most natural choice back then).
February 22, 2013
Am 22.02.2013 07:56, schrieb Sönke Ludwig:
>> I would hope that a future version of Dub wouldn't have any dependencies on Vibe, either. That's an odd bootstrapping arrangement.

Done now on master.

Does anyone know which curl package needs to be installed on Ubuntu so that std.net.curl is happy? I tried libcurl4-openssl-dev but get a large list of unresolved symbols.

February 22, 2013
Am 18.02.2013 22:25, schrieb Moritz Maxeiner:
> On Saturday, 16 February 2013 at 17:10:33 UTC, Sönke Ludwig wrote:
>> With the recent talk about Orbit, I thought it is time to also announce the package manager that we have been working out based on the simple VPM system that has always been in vibe.d. I don't really like stepping into competition with Jacob here (*), but the approach is different enough that I think it should be put on the table.
> 
> Great work, thank you!
> I've taken the liberty of creating Archlinux packages in the AUR for DUB,
> in case anyone is interested:
> 
> Release version:
> https://aur.archlinux.org/packages/dub/
> 
> Trunk version:
> https://aur.archlinux.org/packages/dub-git/

Thanks! I've listed it on the github page: https://github.com/rejectedsoftware/dub#arch-linux

BTW, the build process has been simplified now - dependencies are just DMD+libcurl and building works using "./build.sh" instead of using "vibe build".
February 22, 2013
Am 22.02.2013 10:40, schrieb Sönke Ludwig:
> Am 22.02.2013 07:56, schrieb Sönke Ludwig:
>>> I would hope that a future version of Dub wouldn't have any dependencies on Vibe, either. That's an odd bootstrapping arrangement.
> 
> Done now on master.
> 
> Does anyone know which curl package needs to be installed on Ubuntu so that std.net.curl is happy? I tried libcurl4-openssl-dev but get a large list of unresolved symbols.
> 

On Debian it worked with that same package. Both, Ubuntu 11.10 and 12.04 just generate linker errors...

Well new binaries with libcurl dependency and without libevent dependency are available:

http://registry.vibed.org/download

(No 32-bit Linux version for now)
February 22, 2013
On Friday, 22 February 2013 at 11:01:12 UTC, Sönke Ludwig wrote:
>
> Thanks! I've listed it on the github page:
> https://github.com/rejectedsoftware/dub#arch-linux
>
> BTW, the build process has been simplified now - dependencies are just
> DMD+libcurl and building works using "./build.sh" instead of using "vibe build".

Thanks for the news, I've updated both packages with the correct
dependencies and bumped the release to 0.9.7.
Btw. is there some way in Github to be notified (only) about new tags of a project (So I can update the AUR release package asap)?
February 22, 2013
On Sunday, 17 February 2013 at 17:10:47 UTC, Russel Winder wrote:
> On Sun, 2013-02-17 at 16:08 +0100, Jacob Carlborg wrote:
> […]
>> There are no package managers out of the box for Mac OS X or Windows.
>
> The MacPorts, Fink, and Brew folks almost certainly dispute the first of
> those claims. ;-)

None are out of the box. But they are still very useful !
February 22, 2013
On Friday, 22 February 2013 at 09:40:29 UTC, Sönke Ludwig wrote:
> Am 22.02.2013 07:56, schrieb Sönke Ludwig:
>>> I would hope that a future version of Dub wouldn't have any dependencies
>>> on Vibe, either. That's an odd bootstrapping arrangement.
>
> Done now on master.

Woah! that was fast. I look forward to trying this out!

Regards,
Graham
February 22, 2013
On Saturday, 16 February 2013 at 17:10:33 UTC, Sönke Ludwig wrote:
> With the recent talk about Orbit, I thought it is time to also announce
> the package manager that we have been working out based on the simple
> VPM system that has always been in vibe.d. I don't really like stepping
> into competition with Jacob here (*), but the approach is different
> enough that I think it should be put on the table.
>
> Some may already have noticed it as it's mentioned already on the vibe.d
> website and is currently hosted on the same domain as the old VPM registry:
>
> http://registry.vibed.org/
>
>
> DUB has two important development goals:
>
>  - Simplicity:
>
>    Making a DUB package, as well as using one as a dependency should be
>    as simple as possible to facilitate broad usage, also and especially
>    among language newcomers. Procedural build scripts often scare away
>    people, although their added complexity doesn't matter for bigger
>    projects. I think they should be left as an option rather than the
>    default.
>
>    Turning a library/application into a DUB package can be as simple as
>    adding a package.json file with the following content (mysql-native
>    is automatically made available during the build in this example):
>
>    {
>         "name": "my-library",
>         "dependencies": {"mysql-native": ">=0.0.7"}
>    }
>
>    If the project is hosted on GitHub, it can be directly registered on
>    the registry site and is then available for anyone to use as a
>    dependency. Alternatively, it is also possible to use a local
>    directory as the source for a particular package (e.g. for closed
>    source projects or when working on both the main project and the
>    dependency at the same time).
>
>  - Full IDE support:
>
>    Rather than focusing on performing the build by itself or tying a
>    package to a particular build tool, DUB translates a general
>    build receipt to any supported project format (it can also build
>    by itself). Right now VisualD and MonoD are supported as targets and
>    rdmd is used for simple command line builds. Especially the IDE
>    support is really important to not simply lock out people who prefer
>    them.
>
>
> Apart from that we have tried to be as flexible as possible regarding
> the way people can organize their projects (although by default it
> assumes source code to be in "source/" and string imports in "views/",
> if those folders exist).
>
> There are still a number of missing features, but apart from those it is
> fully usable and tested on Windows, Linux, and Mac OS.
>
>
> GitHub repository:
> https://github.com/rejectedsoftware/dub
> https://github.com/rejectedsoftware/dub-registry
>
> Preliminary package format documentation:
> http://registry.vibed.org/package-format
>
>
> (*) Originally I looked into using Orbit as the package manager for
> vibe.d packages, but it just wasn't far enough at the time and had some
> traits that I wasn't fully comfortable with.

So I'm sorry if that appears completely stupid, but . . .

DUB sounds kind of like dumb. As Orbit sounds very nice, especially since libraries are satellites of mars, so it make sense to see other libs as artificial satellites :D

That is very poor, and have nothing to do with the actual capabilities of each of them.

BTW, it's be great is we could avoid some king of phobos/tango split on that subject and settle on one package manager.
February 22, 2013
On Friday, February 22, 2013 19:29:02 deadalnix wrote:
> So I'm sorry if that appears completely stupid, but . . .
> 
> DUB sounds kind of like dumb. As Orbit sounds very nice, especially since libraries are satellites of mars, so it make sense to see other libs as artificial satellites :D
> 
> That is very poor, and have nothing to do with the actual capabilities of each of them.

Really? I see no problem with either, and if anything, I like dub better because it's shorter (it also starts with d). I don't feel particularly strongly either way though.

- Jonathan M Davis
February 23, 2013
On Sunday, 17 February 2013 at 08:02:41 UTC, Sönke Ludwig wrote:
> To me the most interesting open question is this: Do we actually gain
> from programmatic support for the build description, or does it suffice
> to have a good purely descriptive system? If the former should be true
> for more than 1% of the cases, that would definitely be a good argument
> against pure data.

Well, in the Java world, there is ant. It does the trick, but it's quite ugly.