View mode: basic / threaded / horizontal-split · Log in · Help
February 18, 2013
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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
Re: The DUB package manager
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.
5 6 7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home