Please use a PEP-440 compatible version number

[candrews]

The Python packaging world is moving towards normalized version numbers described in PEP 386 (the currently accepted standard) and PEP 440 (new draft intended to replace PEP 386).

Please use a version number like 0.2.1 instead of just "Git" for the next release, to be compatible with the PEPs.

(Personally, I prefer changing the version number in https://github.com/dol-sen/ssl-fetch/blob/master/sslfetch/__init__.py to '0.2.1dev0' right after I release 0.2.1, and then change it to '0.2.2' just before I release it, so that a random checkout could not be confused with a released version).

In short, the version in https://github.com/dol-sen/ssl-fetch/blob/master/sslfetch/__init__.py should be the same as the version used when creating the git tag and the same as is used when referring to the released archive, and not just the constant string "Git".

[dwfreed]

IMO, commits just to set the version string are useless noise. The version string itself is pretty useless at the moment anyway, because both the code and the API are very much unstable. Once we've decided on a stable API and are ready to make stable releases, then we'll set the version string appropriately.

[dol-sen]

On Sun, 21 Dec 2014 23:03:13 -0800 Craig Andrews notifications@github.com wrote:

The Python packaging world is moving towards normalized version numbers described in PEP 386 (the currently accepted standard) and PEP 440 (new draft intended to replace PEP 386).

Please use a version number like 0.2.1 instead of just "Git" for the next release, to be compatible with the PEPs.

Since this is still in development for use in several Gentoo utilities, it's API's are still unstable, We will be sticking with 0.x numbers for the time being.

(Personally, I prefer changing the version number in https://github.com/dol-sen/ssl-fetch/blob/master/sslfetch/__init__.py to '0.2.1dev0' right after I release 0.2.1, and then change it to '0.2.2' just before I release it, so that a random checkout could not be confused with a released version).

For live builds of git code, I'll look at adding some code to identify clearly the commit it was built as. But since it is a very small lib, and fairly early in it's development, it is not a priority.

There are several primary apps that use this lib that are the main priority so far. We are close to a first release of 2 of them right now.

In short, the version in https://github.com/dol-sen/ssl-fetch/blob/master/sslfetch/__init__.py should be the same as the version used when creating the git tag and the same as is used when referring to the released archive, and not just the constant string "Git".

I agree, but see the previous comments.

If you don't mind my asking, What distro/os are you using this lib? As it is early in it's development I have not yet submitted it to pypi or advertised it's existence.

So far I know of one gentoo specific tool (using ssl-fetch) is being packaged for Arch.

If you have some feature requests or patches, then please submit them.

---

Reply to this email directly or view it on GitHub: https://github.com/dol-sen/ssl-fetch/issues/6

Brian Dolbec

[OOPMan]

Just wanted to let you know that this issue is causing nasty breakages on my Sabayon system (Sabayon is a Gentoo-based distro) whenever I upgrade packages.

During clean-up following package installation I often get messages like

╠  +++ >>>  (6/196) sys-fs/btrfs-progs-3.18
╠    ## Unpacking: sys-fs:btrfs-progs-3.18.4e91e780cab9229dafbb89c1f8d8acc2553e76a0~0.tbz2
╠    ## Installing package: sys-fs/btrfs-progs-3.18
╠    ## [Btrfs filesystem utilities]
╠    ## Updating installed packages repository: sys-fs/btrfs-progs-3.18
╠    ## Cleaning previously installed application data.
/usr/lib64/python2.7/site-packages/pkg_resources/__init__.py:2510: PEP440Warning: 'ssl-fetch (Git)' is being parsed as a legacy, non PEP 440, version. You may find odd behavior and sort order. In particular it will be sorted as less than 0.0. It is recommend to migrate to PEP 440 compatible versions.
  PEP440Warning,
error: No urls, filenames, or requirements specified (see --help)
☢    ## An error occurred. Action aborted.

The annoying thing here is that this just seems to be a warning but it's causing the entire upgrade process to bail out because it thinks an error has occurred...

[dwfreed]

The actual error is here:

error: No urls, filenames, or requirements specified (see --help)

You should file a bug with Sabayon.

[OOPMan]

I did :-)