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.

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?

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.

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.

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>)

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

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.

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.

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/

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.