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.
