Minor: autover could report branch name for pip/git archive

[ceball]

I happened to notice that pip install https://github.com/org/repo/archive/branch.zip for versioneer-using projects seems to result in a version of branch. Although I wouldn't want autover to report a version like that, i indicates the branch name is available.

I believe autover would currently report 0.0.0+gSHA.gitarchive, but if we wanted, this could maybe be something like 0.0.0+gSHA.branch.gitarchive instead.

Seems like a minor issue.

[jlstevens]

I think this could be done but only f the directory name from the unpacked archive preserves the branch name. In other words, it wouldn't work with conda build or pip right now unless we added a lot of really horrible and messy hackery we would rather avoid.

Definitely a valid feature request, the only question is whether it is worth the trouble...

[jbednar]

Doesn't seem particularly useful to me, given that the version number is unavailable anyway.

[jlstevens]

Agreed. I don't see any scenario where we would ask/instruct users to install from a branch using git archive.

[ceball]

I noticed this because I had some mystery with my conda-build behavior, and when I asked for conda-build's version, I was surprised to find it was a branch name. That immediately made me realize I'd previously pip installed a branch of conda-build (via pip install https://github.com/.../branch.zip). So I found it quite helpful. But I agree it's minor.

[ceball]

Would it be worth doing something for situations like holoviz/datashader#610, which if holoviz/datashader#611 is merged (i.e. if autover is used as intended) will turn into some bug that won't immediately be obviously related to versioning?

pip install https://github.com...zip appears to be quite common. One reason for this might be historical. Another reason is that pip install https://github.com...zip is usually much faster than pip install git+https://github..., particularly for repositories with a large history.

Some people doing pip install https://... will discover a problem, which might result in a bug report, but others may never become aware that it's causing a problem (e.g. a version check to be effectively inverted, resulting in some kind of degradation).

Although I suggested above "at least getting the branch name into the version string" (e.g. 0.0.0+gSHA.master.gitarchive), because I thought it would be useful for humans, that wouldn't help something like #610. I also wondered about putting the date (of installation) in. But again, that doesn't help for comparisons (unless you control the comparisons). So would it be better for autover to just error out on installation (by default) if no version is available? With a message something like:

Please build package-x from source using either a git clone or pypi sdist; you appear to be building from some other form of the source, and it's missing the version number.

For example, if you're doing pip install https://...zip, please change to pip install git+https://....

Note that most users should just install a built package via pip install package-x or conda install package-x. Alternatively, development versions are available between releases via conda install -c pyviz/label/dev package-x.

(It would be up to the library developer to allow installation without a version number, by turning off the default 'fail to install if no version available' behavior.)

[jbednar]

Sounds like a message that would save a lot of people from having problems, and/or from thinking our packages have a problem.