-
Notifications
You must be signed in to change notification settings - Fork 87
setup.py loads version information from VERSION #37
Conversation
Previously, setup.py would import the version information from pinject.version. This would trigger pinject's __init__.py to import and load, which would take a roundabout path to importing the decorator dependency. The setup.py script is launched by pip while inspecting the package and dependencies, so this problem will come up in a package sourcing pinject as a dependency even if decorator is declared as a dependency in that package. Referencing: https://packaging.python.org/guides/single-sourcing-package-version/#single-sourcing-the-version The previous method was similar to number 6 (setting the value of __version__ and then importing it). It was changed to number 4 (placing the version in a VERSION file that is read from disk). Given there is a parent VERSION file that is connected to the Makefile, this file is now sourced by setup.py. To ensure it is available when installing pinject, the VERSION file was also added to the manifest. The existing version.py convention is kept for regular use by pinject since that file is readily available to the package when running its source normally. This should fix issue google#35.
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here (e.g. What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
Thank you very much for your contribution! Please:
Then I will merge your PR after it gets at least one approvement from our contributors. |
I signed it! |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
The Travis CI failure was because it couldn't acquire Python 3.3 for Xenial (404 error trying to GET it). Can you check the environment? I don't think that's something I can mess with. |
@rockobonaparte Thanks for making the google bot happy! Let's ignore the Python 3.3 failure from Travis, so your code looks good to me. |
So who signs off now? |
One-week anniversary! Do I need to do anything else? |
ping @trein @rockobonaparte I would like to merge this PR if there are no change requests from other reviewers after 5.31 |
Published to PyPI as v0.14.1 See: https://pypi.org/manage/project/pinject/release/0.14.1/ |
Previously, setup.py would import the version information from
pinject.version. This would trigger pinject's init.py to import and
load, which would take a roundabout path to importing the decorator
dependency. The setup.py script is launched by pip while inspecting the
package and dependencies, so this problem will come up in a package
sourcing pinject as a dependency even if decorator is declared as a
dependency in that package.
Referencing:
https://packaging.python.org/guides/single-sourcing-package-version/#single-sourcing-the-version
The previous method was similar to number 6 (setting the value of
version and then importing it). It was changed to number 4 (placing
the version in a VERSION file that is read from disk).
Given there is a parent VERSION file that is connected to the Makefile,
this file is now sourced by setup.py. To ensure it is available when
installing pinject, the VERSION file was also added to the manifest. The
existing version.py convention is kept for regular use by pinject since
that file is readily available to the package when running its source
normally.
This should fix issue #35.