dub: should we make it the de jure package manager for D?

[Jacob Carlborg]

On 2013-09-11 13:30, Sönke Ludwig wrote:

> Right now it is a pure development tool. It would be very nice to have
> end user installs somehow supported (either by directly installing
> application packages or by generating OS specific packages such as DEB
> or RPM). But since this enters a highly operating specific area and goes
> into direct competition with the OS package manager, I think it needs a
> lot of thought and caution to be generally useful and not possibly do
> more harm than good in the end. But yes, it should be a primary goal in
> my opinion, too.

I'm thinking this type of package manager should be a development tool 
as well. But there are a lot of development tools that are executables 
and not just libraries. Think of your documentation generator. Without 
having looked at it I would assume it's an executable. I have myself a 
tool, DStep, which translate C headers to D modules. This is an 
executable as well.

> Why not _make_ a tag? But uploading zipped packages (or better
> specifying an external link) could be added as an alternative without
> much effort.

I'm not referring to uploading zip packages. Say I have ten tags but I 
only want dub to know about five of them. I want to manually say "make 
the tag v0.0.1 available".

> This is something that may still need some adjustments, but after all
> it's just a default when there is a "source/app.d" or
> "source/<packname>.d" file - an explicit "targetType": "xxx" will fix it
> when it's off.

Yes, but I still don't like the default. To avoid misunderstandings, 
will the dub, by default _both_ build an executable _and_ a library. Or 
will it build an executable _or_ a library?

> "views" is maybe not general enough, but for what it's worth I'm also
> using it on other kinds of projects (e.g. to specify GUI templates).
> "res" might be a bit *too* general, but this could for sure be improved
> somehow. "public" is indeed specific for web stuff, so it may be the
> best to drop it by default.

It's possible to import images, video, audio and many other type of 
resources as well using string imports.

> I've also thought about offering a set of template projects usable for
> "dub init", so that there could e.g. be a true vibe.d skeleton, but by
> default it would be a minimal project with only a "source" folder.

Yes, I was thinking the same.

> Note that there is "dub describe" to extract the information relevant
> for actual building plus there is "dub generate xxx", so nothing is in
> the way of using a separate tool for building. But having integrated
> building IMO is highly convenient and keeping the build description in a
> standardized format is one of the key selling points.

Hmm ok. I would go with two separate tools that are well integrated with 
each other.

BTW, neither "dub generate rdmd" or "dub generate build" seems to be 
working.

> You can put an additional "bar": "==0.0.1" dependency in the main
> package to lock it to a certain version.

I don't want to care about indirect dependencies. That's the job of the 
package manager. If I need to keep track of indirect dependencies then 
the package manager isn't helping much.

> Or, of course, just use "==" in the bar package in the first place.

I might only control the "myproject" package.

> This could also be implemented as a (semi-)automatic function along
> the lines of "dub lock-versions" and  "dub lock-versions --upgrade".

I think this should be the default. I don't want my package to break at 
random just because there's a newer version available of an indirect 
dependency.

I think that a key feature of a package manager should be that any time 
in time you're installing a package of a given version should result in 
the _exact_ same packages, including indirect packages.

> On the other hand it's difficult to make a general statement that this
> is always the best way as this may for example prevent important
> security fixes to get incorporated unless the main package maintainer
> releases an explicit update...

Any update, may it only be security fixes, may break a build. No, 
semantic versions doesn't help here. Locking down by default is the safest.

If the package maintainer doesn't release an update how will you get 
security updates?

It's better if there's an explicit way to update an indirect dependency.

I would rather add "bar": "==0.0.2" on one or two packages to force an 
update of an indirect dependency rather then set "bar:" "==0.0.1" on 
_all_ indirect dependency. This can be quite a large tree if there are 
many dependencies.

At work we have a Ruby on Rails project. It currently uses 160 packages, 
including Rails and all its sub components. It was pure hell before 
"bundler" was released which locks down all package dependencies as I've 
described here. Counting all indirect dependencies as well I get over 
413 packages. Would you like to specify the exact version of all these?

Saying that "bundler" was a salvation for the Ruby community is an 
understatement.

When we get a new employee or a new computer we want, of course, to have 
the _exact_ same packages we use on all the other development machines 
and the ones in production. Otherwise we cannot ensure that everything 
is working the same way on our development machines as on the production 
machines.

Hey, just adding a new production machine we could end up with different 
packages before. Pure nightmare.

-- 
/Jacob Carlborg