On Tue, 26 Aug 2014 17:25:21 -0400, Nick Sabalausky wrote:
On 8/26/2014 7:39 AM, Sönke Ludwig wrote:
After a long pause, the next version of DUB is finally ready. It contains some major changes, of which especially one of them still requires some more careful testing to make sure that there are no regressions.
As you may have already heard or noticed, specifying dependencies with a ~branch used for the version specification has been deprecated, as it became obvious that supporting this is impractical for the overall ecosystem. Please have a look at the wiki for more information about this topic.
I recognize the very real problem this latest dub is trying to solve,
and I have to admit I agree to the extent that perhaps "~master"
dependencies should be banned or at the very least not be made so easy &
tempting.
But I find the general approach troubling.
I love that we have dub, and I genuinely want to get more use out of
it. But as I've partially mentioned in another thread (that time I was
talking within the context of project building), my one big roadblock
problem with dub is it tends to be fairly "my way or the highway". If
your project wants to use dub (either for dependency management,
publishing or building), then it frequently feels like dub demands your
project to be designed and managed "the dub way", all or nothing.
Consequently I'm unable to rely on dub as much as I'd like.
Some things have gotten a lot better. For example, the old
requirements that the sources be in a directory named "source" and that
the "main()"-containing file be named "app.d" are mercifully long gone.
But I still keep getting the feeling that dub hasn't quite shaken the
general "the dub way or get out" approach to things.
I can't even remember when "source" and "app.d" have been requirements. The philosophy has always been to gently push into a standard direction (for the sake of a coherent ecosystem), but to always allow full customization. So if you have any concrete examples (apart from the version management scheme), we should probably get them fixed.
I'm more than willing to get into actual specifics and submit pulls, of
course.
As for my thoughts on this specific matter at hand, the subject of
branch dependency deprecation:
- Master Branch Dependency:
I'm fine with eliminating broad branch dependencies on the master
branch. Although, if it doesn't already exist (I think it may?) I'd like
to see a way for a user to get around that for their own project (just
not for projects within the dub's public repo). This can, and perhaps
should, be somewhat of a bother to do, but it should at least be
possible if it isn't already. Manual overrides are important.
Have you seen the linked article? It talks about the different possibilities to still use branches (dub.selections, local overrides, automatic associations of working copies with the latest version tag, or path based dependencies - interesting for use with git submodule or subtree).
- General Branch Dependency:
I feel like eliminating all branch dependencies (ie, not just on
master) may be overkill. I haven't actually checked, but I'm guessing
the vast majority of the problems we have are specifically on "master"
branches. Has there really been much issue with non-master branches so far?
It's actually the opposite. If just master would be supported, it would be possible to invent rules to make it play nice with versions (at the expense of forcing certain semantics on how projects have to use the master branch). But the general issue is that there is no defined relationship between versions and branches, so it is simply not possible to resolve conflicts in a meaningful way when the same dependency is referenced in the same dependency graph by both, a branch and a version. The result is (with historical evidence) a divide of the package ecosystem into packages that use branches and those that use versions. This is nothing short of a catastrophic design failure.
Eliminating these seems like throwing the baby out with the bathwater: I
think it'd be entirely reasonable for a project (and this fits within
the spirit of semantic versioning) to create and maintain
no-breaking-change branches. For example, v1.3.1, v1.3.4 and v1.3.27
could all be tags on a stable "v1.3.x" branch. That may have various
pros/cons, but I don't think it's appropriate for dub to categorically
eliminate things like this unless there actually IS a real and
significant problem that can only be solved that way. I'm not sure
that's actually the case here, my understanding is that only "master"
has been a real issue.
There is a very real issue as mentioned above. It would be possible to detect certain branch name patterns and assign certain semantics to it, but that would be a completely different approach than the branch support that was there before. We could think in this direction, but I'm really skeptical if that would actually be desirable.
Speaking of versioning, I like semantic versioning. A lot. I'm all
for it. But...dub has no business mandating it or otherwise getting in
the way of projects/tags that, for whatever reason, don't use it. Not
allowing dependencies on arbitrary tag names (for example:
"johnnys-super-release" or "stupid-code-name-like-horny-hippo") is just
plain straight-jacketing. (At least, I think that's still a limitation
of dub, or has it been lifted?) Dub's add-local/path/override, while
nice features, are not sufficient for this. Depending on a specific tag
is a simple thing, it should be simple to do. Tossing it in the
"version" field should "just work".
Look at it this way: The fact that DUB supports tags at all is something that I really wanted to get in for convenience (with quite some opposition). However, the system is generally designed to be able to work independently of a source version management system. Also, apart from Go's crippled approach to package management, DUB is the only package manager that I know which doesn't exclusively work with versions.
But a really critical issue with plain tags and branches is that they either support no bounds (branches) and thus can break dependent packages with every commit (even if unintended), or they are fixed to a single commit, so that any other package that references the same package is very likely to produce a conflict. This is especially true for raw tags or commits, because they have no visible relation to either branches or versions.
The essence is that branches, tags and commits have a pretty destructive effect on the ecosystem. The result, I'm convinced, will always be a very brittle and inflexible mesh of packages that will severely hamper a healthy long-term development.
Much the same as tag names. This is an occasionally-necessary escape
hatch. Especially if the "~master" dependency is eliminated. Sometimes
you need a specific commit for whatever weird reason, and requiring
cooperation from the given project's maintainer is both insufficient and
unnecessary. Dub's add-local/path/override is also an insufficient
solution here, as is this new "dub.selections.json" thing that I don't
even understand yet. This is a simple thing, I should be able to expect
tossing a commit hash (or arbitrary tag name) into the "version" field
of a dependency to "just work".
See above. The problem is the effect on the ecosystem that this has. If such a feature is there, it will inevitably be used and in turn forces other packages to do the same (or they will produce conflicts). In the end, such things will go viral and create two mutually incompatible partitions - one that uses commits (or branches) and one that uses versions.
One thing I do think would be a good idea, if it isn't already in
place (maybe it already is?), is if dub's official repo required newly
submitted repos to already contain at least one tag before the new
project actually becomes "active" in the repo and can start being used.
A single existing version tag is required since a while for being able to register a package. The percentage of packages without version tags fortunately dropped from about 60% to about 30% because of this.
Having said all this, if it would turn out to be really necessary, we could of course, instead of actually deprecating them, just disallow branch dependencies for public packages. However, mostly due to the feature that assigns a locally checked out branch to the latest version that it derives from, so far I haven't found a use case that would actually make this necessary.
