0

I have two versions of my python build: 

16.1206.43542
17.0817.221945+f4cc396

The only really difference I can see is the ending metadata. When I run pip install package, the version 16.1206.43542 is installed and not the latest. Is this the proper behavior? I would have thought pip would have honored the metadata, and installed the later package?

Thoughts? Ideas? Any would be welcomed. For transparency, I am adding the sha from a git build into the version.

phd
  • 82,685
  • 13
  • 120
  • 165
supreme Pooba
  • 868
  • 1
  • 7
  • 14
  • Not enough information. What package have you installed? Where from? – phd Aug 17 '17 at 23:30
  • I don't see how that is relevant. It is a private package, not public. But considering the command is the same, why would it matter what the package is? – supreme Pooba Aug 18 '17 at 19:59
  • I guess I am not explaining myself. I have a custom package that I am building myself. I have the above versions. If I run pip install on those versions, the earlier one overrides the latter. – supreme Pooba Aug 21 '17 at 17:06
  • *I am not explaining myself* Yes, that's the problem with your question. *I have a custom package that I am building myself.* That I understood… *If I run pip install on those versions* …but I don't uderstan this. Where are those packages? In files? In some private index (local pypi/devpi/etc)? In the latter case it's hard to explain anything as we don't have access to your private index. May be the newer version was not properly built or properly uploaded, how do we know?… – phd Aug 21 '17 at 19:35
  • Ah! I get you. I have built this package a lot. The setup.py is doing the building and deploying to a private index. If I point to a specific version, the version installs with no problem. So: pip install package==16.1206.43542 pip install package==17.0817.221945+f4cc396 both install. But when I do pip install package, it installs the smaller of the two...all because of the +f4cc396 on the end. – supreme Pooba Aug 21 '17 at 21:11
  • Public PyPI sometimes has [the problem of not showing the latest version](https://stackoverflow.com/q/45385941/7976758). The author of `furigana` uploaded a new version (0.0.7.1) to update the index. – phd Aug 21 '17 at 21:34
  • Great insight, however, this is not the case. The versions are there. They show up if you give `pip install package==`. The version is listed, it just doesn't register as the greater version. It installs the lesser. – supreme Pooba Aug 22 '17 at 21:25
  • `17.0817.221945+f4cc396` is obviously not a valid [Semantic Version](http://semver.org), the minor version field contains a leading zero. Either this tooling doesn't actually support SemVer, in which case, please remove that tag from this thread, or there is a bug that generates invalid semver strings. – jwdonahue Jan 11 '18 at 05:36
  • jwdonahue - I understand the "not a valid Semantic Version" statement, however, if not valid, it shouldn't show in the list of packages when calling pip install package==. It just seems strange to see the thing in a list and then it doesn't work. – supreme Pooba Jan 16 '18 at 17:47

1 Answers1

0

I looked at this, and found that the correct answer is that anything following the normal Semantic Versioning, it labels that build as a pre-release build and must then be explicitly called to be installed, normally identified with a '-'. https://semver.org/ (Topic 9)

For pip install The version must be a NON pre-release build to be automatically installed.

supreme Pooba
  • 868
  • 1
  • 7
  • 14