Version specification priorities

prezi / snakebasket

A smarter, recursive pip.

84 stars 4 forks source link

Version specification priorities #2

Closed abesto closed 11 years ago

abesto commented 11 years ago

Explicit is better than implicit: use foo.git@reallylongsha1 over foo.git when both are present. foo.git is the same as foo.git@master.

Except that maybe someone really really wants master. So here's what I propose:

Always prefer foo.git@anything over foo.git
foo.git@anything should conflict with foo.git@anything-else. Doesn't matter if the anything and the anything-else are branches, commits, hashes or anything.

cassus commented 11 years ago

Most of the time changes are backward compatible, this should be the assumption of the package system. If there's an issue I'll need to fix it anyhow. Making 1.0.1 and 1.0.2 incompatible by default would generate lots of extra administration for me and I don't see the big benefit.

abesto commented 11 years ago

We were bitten by a change that wasn't only backward incompatible, it actually broke anything that used it. There were no AT-s at the time, so it got out into "production" (there's no real production for dynapps yet, but it was deployed).

Maybe we could have different version resolution rules, could be set per project. That feels overkill though.

abesto commented 11 years ago

There's an option for that.