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

setup.py overwrites nml/__version__.py #112

Closed
matthijskooijman opened this issue May 1, 2020 · 2 comments
Closed

setup.py overwrites nml/__version__.py #112

matthijskooijman opened this issue May 1, 2020 · 2 comments

Comments

@matthijskooijman
Copy link
Contributor

@matthijskooijman matthijskooijman commented May 1, 2020

Another problem cropped up in the Debian package: Running ./setup.py overwrites the nml/__version__.py supplied in the source tarball.

Normally, this is ok, since it gets the nml tag or git hash that is being compiled. However, my Debian package also use git, so when I try to build the .deb from my git repo, the version.py gets overwritten with an incorrect git hash or tag.

I tried adding a Debian-specific patch to prevent this, but typically a Debian package is cleaned before applying patches, so then the version number is already gone, so this should really be fixed in the tarball.

I wonder if the release tarball could somehow know that it is a release tarball and prevent its version.py from being overwritten? Alternatively, passing some option to setup.py or setting some environment variable that would prevent the git version detection and forces using the existing __version__.py would also work fine.

@matthijskooijman
Copy link
Contributor Author

@matthijskooijman matthijskooijman commented May 4, 2020

I tried adding a Debian-specific patch to prevent this, but typically a Debian package is cleaned before applying patches, so then the version number is already gone, so this should really be fixed in the tarball.

Turns out this was not a problem after all. The changes made to __version__.py were only linebreak changes, so I think that with the fixed line endings in current master, I should be able to make this work by patching out the git version detection.

Specifically, this works for two build workflows:

  • Build directly from a git checkout with dpkg-buildpackage. This applies patches before doing anything else.
  • Build using gbp buildpackage in a chroot (this is my default workflow). This does indeed clean before applying patches, but it does this in an export of the git repo, which excludes a .git directory. So this does regenerate __version__.py, but without changing its contents (except for newlines previously...).

It would still break if you would directly call ./debian/rules binary or ./debian/rules clean in a git checkout without applying patches first, but I guess that's acceptable.

So, I think that the current master might actually allow a proper Debian package to be generated. It might still be good to see if this version number stuff can be a bit more elegantly fixed (e.g. not requiring a Debian patch maybe), but given the complications in #115, maybe requiring some changes in setuptools_scm, maybe release 0.5.1 first and solving this later would be better?

I'll test a tarball generated from master to confirm that there are no additional problems and report back here.

@matthijskooijman
Copy link
Contributor Author

@matthijskooijman matthijskooijman commented May 4, 2020

I'll test a tarball generated from master to confirm that there are no additional problems and report back here.

Just tested a tarball generated from master and that works as expected. I still have to patch out the git-version-detection, but that seems fine for now.

So, how about releasing 0.5.1 from current master, and iterating on this issue and #115 after that?

Note that it seems the auto-removal deadline in Debian has been extended (probably because the bug was reassigned by someone), so I'm not in a bug hurry, but it seems good to still just move ahead with this release and evaluate further improvements with a bit more time?

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

Successfully merging a pull request may close this issue.

None yet
1 participant