I figured what is wrong with ours currently has more to do with whatever arbitrary setuptools version I was using being an old version that can not interpret anything in the [metadata] section of setup.cfg (this was added in setuptools version 30.3.0 and re https://github.com/pypa/setuptools/pull/862). That being said after doing some reading on community standards regarding version parsing on [PEP 39] (https://www.python.org/dev/peps/pep-0396/) and looking at some other open source projects I follow, I went with peeling the version number off the fileflow package's __version__ attribute in setup.py directly. This was also semi informed by a small poll of 3 situations whereby we determined setuptools might be version 3.3, 12.1, 18.2, or 32.3.1 depending when you last installed virtualenv/pip/setuptools itself.
For example this was the problem for me locally, against setuptools version 18.2. I am explicitly installing the commit before this PR:
(fileflow)fileflow $ pip install git+git://github.com/industrydive/fileflow.git@f71973c83884b23d1bb70d64aadcb50da776bf60#egg=fileflow
Collecting fileflow from git+git://github.com/industrydive/fileflow.git@f71973c83884b23d1bb70d64aadcb50da776bf60#egg=fileflow
Cloning git://github.com/industrydive/fileflow.git (to f71973c83884b23d1bb70d64aadcb50da776bf60) to /private/var/folders/f6/b427f1ns42n4sj9szglhcpsc0000gn/T/pip-build-9pOsUJ/fileflow
Could not find a tag or branch 'f71973c83884b23d1bb70d64aadcb50da776bf60', assuming commit.
[ ... skipping some stuff here ... ]
Installing collected packages: fileflow
Running setup.py install for fileflow ... done
Successfully installed fileflow-0.0.0
vs after this PR; commit 10be84 is the latest in this branch:
(fileflow)fileflow $ pip install git+git://github.com/industrydive/fileflow.git@10be84a355b53c22c1fb7ffe61f1cdfdb4faf6da#egg=fileflow
Collecting fileflow from git+git://github.com/industrydive/fileflow.git@10be84a355b53c22c1fb7ffe61f1cdfdb4faf6da#egg=fileflow
Cloning git://github.com/industrydive/fileflow.git (to 10be84a355b53c22c1fb7ffe61f1cdfdb4faf6da) to /private/var/folders/f6/b427f1ns42n4sj9szglhcpsc0000gn/T/pip-build-9ogh2B/fileflow
Could not find a tag or branch '10be84a355b53c22c1fb7ffe61f1cdfdb4faf6da', assuming commit.
[ ... skipping some stuff here ... ]
Installing collected packages: fileflow
Running setup.py install for fileflow ... done
Successfully installed fileflow-0.0.3
We could require our build process to use a minimum setuptools version so that we are >30.3.0 and leave it the old way, but this was more in line with what I saw elsewhere and works back through many setuptools versions.
I also left this at the same point release since I was just fixing the metadata, which I felt doesn't warrant a new release number.
I figured what is wrong with ours currently has more to do with whatever arbitrary setuptools version I was using being an old version that can not interpret anything in the
[metadata]section ofsetup.cfg(this was added in setuptools version 30.3.0 and re https://github.com/pypa/setuptools/pull/862). That being said after doing some reading on community standards regarding version parsing on [PEP 39] (https://www.python.org/dev/peps/pep-0396/) and looking at some other open source projects I follow, I went with peeling the version number off the fileflow package's__version__attribute insetup.pydirectly. This was also semi informed by a small poll of 3 situations whereby we determined setuptools might be version 3.3, 12.1, 18.2, or 32.3.1 depending when you last installed virtualenv/pip/setuptools itself.For example this was the problem for me locally, against setuptools version 18.2. I am explicitly installing the commit before this PR:
vs after this PR; commit 10be84 is the latest in this branch:
We could require our build process to use a minimum setuptools version so that we are >30.3.0 and leave it the old way, but this was more in line with what I saw elsewhere and works back through many setuptools versions.
I also left this at the same point release since I was just fixing the metadata, which I felt doesn't warrant a new release number.