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

Sönke Ludwig sludwig at outerproduct.org
Wed Sep 11 09:11:10 PDT 2013


Am 11.09.2013 17:01, schrieb Jacob Carlborg:
>> 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".

It will only look at version tags of the form vA.B.C(postfix) any reason 
to hide one of those? It could be added as a feature to the registry, 
but is there a compelling use case to warrant the costs?

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

"or", you can choose which using "dub --config=library" or "dub 
--config=application" (the default).

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

Works for me, but master was broken for some hours. Maybe you caught a 
bad version?


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

I just don't know if that can be generalized to everyone or at least the 
majority of users. Maybe this is a good topic for starting a wider 
discussion/poll.

>
>> 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 used correctly, by definition, it _does_ help. Reality, especially in 
the fast moving D environment, may be different, though. However it 
seems to work quite well in the C world.

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

By upgrading and getting updates of indirect dependencies, even if the 
main package wasn't updated.

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

Note that I definitely don't oppose to the idea of integrating such a 
mechanism -- I do see the value. The question is if it should be the 
default or not (Bundler is opt-in after all), taking into account for 
example how well it interacts with branches and different use cases. I'm 
quite open there, but I first have to play that through with all of my 
stuff before I can voice an opinion.


More information about the Digitalmars-d mailing list