Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python setup clean modifies the sources #64

Closed
doko42 opened this issue Apr 30, 2020 · 3 comments
Closed

python setup clean modifies the sources #64

doko42 opened this issue Apr 30, 2020 · 3 comments

Comments

@doko42
Copy link

doko42 commented Apr 30, 2020

pebble has a rather unusual setup.py, which modifes the sources during the build, even when calling setup.py clean. Seen when packaging pebble. Maybe make this more robust, such that things are not modified, or not appended multiple times? My current workaround is not to call write_version at all.

--- python-pebble-4.5.1.orig/setup.py
+++ python-pebble-4.5.1/setup.py
@@ -17,7 +17,7 @@ def package_version():

 version = read_version(version_path)
 write_version(version_path, version)
  • write_version(init_path, version, mode='a')
  • #write_version(init_path, version, mode='a')

    return version

@noxdafox
Copy link
Owner

noxdafox commented May 6, 2020

Hello,

pebble is relying on git tags to infer the version of the package and correctly propagate it.

It does so by adding the version number when running setuptools.

Are you trying to port pebble to some packaging system such as Debian-apt or Fedora-rpm?

@doko42
Copy link
Author

doko42 commented May 7, 2020

well, if you call "building from source" as "porting", yes. The source packages never have access to the VCS.

noxdafox added a commit that referenced this issue May 9, 2020
The previous versioning logic was inferring the package version
through its VCS tag. This mechanism had few shortcomings:

 - The `setup.py` was modifying the module sources causing issues in
   build systems
 - As the VCS might not be installed on target machines,
   an extra `version.py` file had to be provided in the package
 - As the code was modified during packaging time, the source code
   with the correct version would be one commit ahead of the actual
   tagged version

The new logic inverts the version control. The version is controlled
within the module `__init__.py` file. When releasing a new version,
the module file is updated and committed. The tag is then inferred
from the module file itself.

Signed-off-by: Matteo Cafasso <noxdafox@gmail.com>
@noxdafox
Copy link
Owner

Release 4.5.3 should fix this issue. Please re-open it in case problems persist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants