February 18, 2013
On Monday, 18 February 2013 at 11:51:14 UTC, Nick Sabalausky wrote:
> ...

Ugh, have you ever tried to do it in practice? Because I have been maintaining few packages, primarily for Arch Linux, and it is not even remotely close to what you say. There may be some bureaucratic headache to get stuff into official Debian repos, but you always can create your own mirror, like it was done here for D stuff: http://code.google.com/p/d-apt/wiki/APT_Repository . Packaging itself is always simple and requires close to zero efforts.

And saying you don't want to learn OS package manager to distribute stuff for it is like saying you don't want to learn OS kernel API to write drivers to it. Sure it is so better to be forced to learn dozens of language-specific package & build managers to just get a single application working. Software ecosystems are evil.
February 18, 2013
On Mon, 18 Feb 2013 14:02:16 +0100
"Dicebot" <m.strashun@gmail.com> wrote:

> On Monday, 18 February 2013 at 11:51:14 UTC, Nick Sabalausky wrote:
> > ...
> 
> Ugh, have you ever tried to do it in practice?

'Course not, because why should I? With OS-independent language package managers, all I have to do is toss into a trivial ./build script the few commands (if even that much) needed to grab the dependencies (via DUB/Orbit/Gems/whatever) and launch my buildscript, with only minor tweaks for the build.bat variant (which most Win users won't even need to use at all since a prebuilt .exe is pretty much guaranteed to work out-of-the-box). That's *all* I need for it to work for *everyone*. *And* nobody needs to deal with a long list of "If you're on OS A do this, if you're on OS B do this, OS C do that, etc."

Or I can use the OS-based stuff and have it only work for *some* people on *some* OSes. Yea, that sounds really worthwhile. Even if it *is* super-simple, as a lib or app developer I still have no reason to even do so at all in the first place.

> Because I have been maintaining few packages, primarily for Arch Linux, and it is not even remotely close to what you say. There may be some bureaucratic headache to get stuff into official Debian repos, but you always can create your own mirror, like it was done here for D stuff: http://code.google.com/p/d-apt/wiki/APT_Repository . Packaging itself is always simple and requires close to zero efforts.
> 

Yea, I'm sure it is a lot simpler if you're primarily targeting just one linux distro and little else. ;) Not simpler for your users, though. :/

> And saying you don't want to learn OS package manager to distribute stuff for it is like saying you don't want to learn OS kernel API to write drivers to it. Sure it is so better to be forced to learn dozens of language-specific package & build managers to just get a single application working.

If you're dealing with a handful of different languages just to write one program, you're already doing it wrong to begin with. (That's the generalized "you", I don't mean you specifically). And even if that weren't the case, how is needing to deal with a variety of different OS-specific package managers just to release one program any better?


February 18, 2013
On Monday, 18 February 2013 at 13:42:49 UTC, Nick Sabalausky wrote:
> ...

You are mixing together programmer needs and end-user needs. As package manager takes care of dependencies, it naturally leaks as a mandatory tool to use for someone who want to install your application. And guess what? Those freaking ruby gems almost never "just work" because of some forgotten requirements. I have stumbled upon this just a week ago, trying to install Redmine on Arch Linux : ImageMagick version in repo was too new and all build/install system just died in pain with some obscure error. Was forced to study rake file to tweak dependencies. A lot of pain instead of just having clean full dependency list that I can take care of myself and some generic widely adopted build system.

If you want to target specific OS or distro, you'll need learn a good part about its design and environment anyway, at least to adjust your code. If you have not done it, better not pretend your software actually  targets it and let enthusiasts take care of it. I have done PKGBUILD's and .deb's so far and those are so damn simple comparing to writing proper cross-platform code.
February 18, 2013
On Monday, 18 February 2013 at 14:14:30 UTC, Dicebot wrote:
> ...
tl; dr: Care not about developer, he can adjust. Care about end-user who has single OS and is forced to deal with miriads of different package systems or, even better, binary bloat of programs that try to ship every single dependency with it.
February 18, 2013
Just added a new version with support for GDC and LDC (e.g. --compiler=gdc or --compiler=ldc2) and some fixes for the VisualD and Mono-D project file generation. It builds now directly using the specified compiler by default - rdmd can still be used by passing --rdmd to the command line.

"dub init" now also creates example source code that actually compiles (without vibe.d as a dependency) and invoking dub outside of a package directory now gives a nicer error message.

(Binaries: <http://registry.vibed.org/download>)
February 18, 2013
On 02/17/2013 12:47 PM, Nick Sabalausky wrote:
> Then on the flipside, we have the example of INI files: Definitely a
> purely data-language, definitely not an embedded DSL, and yet that's
> never been a hindrance for it: it's been a lasting success for many
> things. And the only time anyone complains about it is when more power
> is needed. (And no, I'm not suggesting DUB or Orbit use INI files.
> Again, specifically because more power is needed here.)

I also went with INI files for an even simpler build/package tool I wrote a year ago.
https://github.com/dawgfoto/dpk
February 18, 2013
On 02/16/2013 06:10 PM, Sönke Ludwig wrote:
> 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/
>

Thanks for finally tackling this important necessity in a pragmatic manner.

> http://registry.vibed.org/package-format

Meets what you'd expect from a package tool on a two page spec.

> https://github.com/rejectedsoftware/dub

The code looks modular/extensible enough to add whatever specialized needs will come up.

February 18, 2013
On 2/16/13, Sönke Ludwig <sludwig@outerproduct.org> wrote:
> http://registry.vibed.org/

Why does dub automatically try to build an executable? I wanted to create a library package but I don't see from the docs how to do this.

I also think it's counter-intuitive that running dub with no arguments will autobuild the project, this should be a a separate 'build' command.
February 18, 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.

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/
February 18, 2013
On Mon, 18 Feb 2013 15:17:05 +0100
"Dicebot" <m.strashun@gmail.com> wrote:

> On Monday, 18 February 2013 at 14:14:30 UTC, Dicebot wrote:
> > ...
> tl; dr: Care not about developer, he can adjust. Care about end-user who has single OS and is forced to deal with miriads of different package systems


First of all, I *am* thinking about the end-user. OS-based package managers frequently *do* suck for the end-user:

http://cran.r-project.org/bin/linux/ubuntu/README.html

Look at all that idiotic bullshit the users have to deal with just for something that *could* have been a trivial download/extract/run (Or an even simpler "wget ... -O fetch-and-build.sh && ./fetch-and-build.sh"). And that page is *just* for Debian/Ubuntu.

And then there's stuff like this which isn't much better:

http://www.claws-mail.org/downloads.php?section=downloads

Secondly, where do you get that crazy idea that all end-users only ever have one OS to deal with? ATM, I've got a couple windows machines, a kubuntu desktop (old), and a debian 6 server. And that's not counting VMs.

Other people have even more than that, and it doesn't help anyone to
have a totally different set of instructions for doing the same
damn thing each one. *I* can install any version of DMD I want on any
of my systems by doing this:

dvm install 2.0xx

Same damn task, same damn command, character-for-character, on freaking everything. You're seriously going to try to tell me that's *worse* for me than having to do it totally different on each system?

And finally, there's two types of users here, lib users and app users:

Libs: If they're interested in your lib, then they're already familiar with the language's package manager.

Apps: If your user has to deal directly with any of the language-based packager managers involved, then your buildscript sucks. But that's just for actually compiling. If your user has to deal with any language's package manager merely to *run* your app, then, well again, then you're doing something wrong. (Such as maybe using Python: I'll agree that Gem is fucking shit - more than half the times I've tried to install something it would just vomit out a Traceback.)

Language-based package managers are a developer thing, not an end-user thing. Even if your app is using a language-based packager manager, that doesn't mean the end-user even needs to touch it directly.

>or, even better, binary bloat of
> programs that try to ship every single dependency with it.

Right, binary bloat in this >1GB HDD age is sooo much worse than running into unexpected version incompatibilities and conflicts.