On Tue, 26 Aug 2014 17:25:21 -0400, Nick Sabalausky wrote:
I'm more than willing to get into actual specifics and submit pulls, of
course.
I would like to see another post about the issues you have.
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.
- 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?
I would like to ban everything except version tags from the repository.
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.
If there are tags based on that branch, use those.
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 real and significant problem. One big problem I see is that you don't know what you'll get. If you track a branch you can end up with different code if you install the application six months later. And yes, even if you use Semver you're code can break.
- Tag Names:
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".
- Commit Hashes:
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".
I like the way Bundler work in this regard. It allows you to specify any Git repository in your dependency file. You can specify a branch, a tag, a specific commit, anything that Git supports. The requirement is that the Git repository contains the sources for a Ruby gem. It also allows you to specify a local path, useful during development.
I have found uses cases for all these features when working with Ruby. Local path, specific git tag and so on.
I think it would be nice if Dub could support that. But, the important thing is that nothing of that is allowed in the repository. You can have a Dub package in the repository that depends on a Git repository but a specific Git commit, branch or arbitrary tag will never be available in the repository.
- Official Repo:
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.
Sounds like a good idea if not already present.
/Jacob Carlborg