rdiff-backup --version from Ubuntu PPA show DEV #305
Comments
ikus060
changed the title
rdiff-backup --version from Ubuntu PPA show DEV
|
The PPA is not intended for production use. Install rdiff-backup 2.0 from the official repositories for that. The PPA is only for development use and testing, so having it DEV is kind of the correct thing. |
|
I don't agree with this statement: it would mean that users might report a "DEV" version, which isn't helpful to understand which version they might have been actually using as they got a problem. |
|
Something that might help to fix the DEV problem. I'm using this environment variable to force the version for dpkg-buildpackage |
|
Adding something like |
|
The bug report was missing the crucial line. This is the current output of rdiff-backup when installed from a PPA as the steps in above outlined: This seems absolutely correct to me. Users of the PPA are running a development version and However, when it is installed from the official Ubuntu repositories where we have a production 2.0.0 release, it says: This is not good.. |
|
I can't find where this I tested @ikus060 tip, but it did not work: .deb build: |
|
To answer your question, @ottok , the version Sorry for the late thought but I can't imagine that we're the first using setuptools_scm to version our software. Isn't it possible to identify Debian packages having python[3]-setuptools-scm as build dependency and see how they solve this issue? In this particular case, the issue is the tag (perhaps replacing Hope this helps. |
|
There are indeed other packages using python3-setuptools-scm but I don't see any of them doing any particular trickery to the version in their rules file. E.g.: https://salsa.debian.org/python-team/modules/python-dateutil/-/blob/debian/sid/debian/rules |
|
I looked into it:
OK, back to jsonschema:
If I compare with https://salsa.debian.org/python-team/applications/rdiff-backup/ the tagging difference is what appears to me most relevant. If this doesn't help, the next step would be to contact the package maintainer(s) and ask them if they know how they've solved the issue. |
|
Hi!
python-jsonschema in Debian used to use SETUPTOOLS_SCM_PRETEND_VERSION
https://salsa.debian.org/openstack-team/third-party/python-jsonschema/-/commit/15fea0bc536780b49e47b3b7ccb052511347b22f
They might be still using it but it is maybe injected from the pybuild
somewhere.
I will try to checkout how to use SETUPTOOLS_SCM_PRETEND_VERSION.
Here is one that stil explicitly uses SETUPTOOLS_SCM_PRETEND_VERSION:
https://salsa.debian.org/python-team/modules/cherrypy3/-/blob/master/debian/rules
Here is another package on Python setuptools scm that did version handling
changes recently:
https://salsa.debian.org/python-team/modules/python-tenacity/-/commit/4142bdbd7da44c5bc040ac5319a91675ce0e51fd
Two packages that depend on setuptools scm but their rules files are very
simple and have no extra tricks there:
https://salsa.debian.org/debian-astro-team/glue/-/blob/master/debian/rules
https://salsa.debian.org/python-team/modules/automat/-/blob/master/debian/rules
|
|
Another avenue could be loading /usr/share/dpkg/pkg-info.mk and using DEB_VERSION_UPSTREAM and DEB_VERSION |
|
I wrote a custom autopkgtest in Debian for this to catch it: And tested various methods, such as: ..but they all failed: Dev branch at https://salsa.debian.org/python-team/applications/rdiff-backup/-/commits/dev-otto Do you @ericzolf have ideas on how to inject the version to the build as it does not seem to use |
|
We had the same issue for the Windows build until we built the wheel and packed the generated file with I installed the wheel locally for my tests and the package metadata is under: And I see that Frank packaged his stuff with those files: Perhaps you only need to package the metadata files? |
|
The Debian build produces these: They are also included in the package like all other files generated by the build:
I don't under stand this, maybe I am missing some context? @elMor3no Do you have experience with Python packages, could you try to solve this? |
|
What is the content of the egg files, especially PKG-INFO? |
|
If you want, I can try to reproduce the build on my system and see if I stumble upon something, but I would need few instructions to start with: which Debian, which Git repo/branch and which command to call (my Debian packaging days are far away). |
|
I'm seeing this on some Centos systems as well, is it possible it's coming from something on those systems at runtime or on install? Both of these two are using the EPEL packages: [telsin@host0 ~]$ rpm -qa | grep rdiff-backup [telsin@host0ch1 ~]$ rdiff-backup -V |
|
@telsin can you also ensure you are running the version of rdiff-backup that comes from the RPM, by doing |
The problem here is that the version that I was afraid we end up with something like this when we discussed the SCM->version thing back in #66 (comment). There was also some discussion in #152 on what the fall-back should be when there is no git repo. Something needs to be engineered into https://github.com/rdiff-backup/rdiff-backup/blob/master/src/rdiff_backup/Globals.py#L29 maybe? |
|
FYI, when I am using Ubuntu 20.04 (Focal) with the standard version of rdiff-backup (that was automatically upgraded from 1.2.8 when I upgraded the system from 18.04), I see: so - no bug? |
|
I cannot reproduce that. What version exactly do you have I wonder? Are you using it from the PPA or? What does |
the 'rpm -V rdiff-backup' returns nothing on my system, even when run directly on the installer package with -p. This definitely seems to be coming from something in the environment, not the binary. I note that systems that return version DEV have older python3 versions installed, alongside the latest for my distro, 3.6.8, using the same package. vs |
|
A new Python version does not fix it. However installing setuptools makes it work. This is kind of stupid though, needing an external library just to know your own version (which is a static string that never changes). |
|
appears to fix it on Centos 7x as well. |
|
@ottok, in answer to your question: This did not come from a PPA. I always had rdiff-backup 1.2.8 on Ubuntu 18.04 (originally installed with |
|
I can confirm that the installation of python3-setuptools solves the issue. Just make it a dependency and we're done. In a container started with |
|
Added python3-setuptools (which pulls in 3 MB of software on the system) as a manual build-time dependency and now tests pass at https://salsa.debian.org/python-team/applications/rdiff-backup/-/jobs/847310 and the version is printed. This somehow feels like the wrong solution. With the "git to version" thing we want to avoid having to manually put the version string in the sources and have it end up there automatically instead, thanks to setuptools-scm. Now we end up running setuptools to simply read the version string during run-time from somewhere else and it has nothing to do with git anymore. Something feels wrong but I can't put my finger on it. |
|
During build, setuptools takes the version from Git and places it in PKG-INFO & Co; during runtime, setuptools takes it back from there and outputs it. Do you update accordingly the |
|
I admit, while I'll add a requirement for setuptools in the rdiff-backup RPM, but I agree with @ottok that pulling in a large package just to get the version number printed seems to be overkill. There should be a better way to do this. |
|
... but I think getting the bugixes into major distros is more important... |
|
I would also suggest that we first close the bug (no proper versioning) and then create an enhancement request (avoid pulling setuptools as runtime dependency). |
|
Yes, I'm okay with that. |
) FIX: add python3-setuptools as a run time dependency to Debian package so --version works and doesn't output DEV, closes #305.
|
setuptools is almost always installed or required for python packages. Very
few packages are still using distutils alone.
Considering this fact, I would say it's very common to have setuptool as a
dependency and I'm not considering this a flaw.
…On Mon, Jul 6, 2020 at 2:30 AM Eric L. ***@***.***> wrote:
Closed #305 <#305> via
#417 <#417>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#305 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHA5I4DCOMJVLM7NFGMGWDR2FVPNANCNFSM4LPIMMZA>
.
--
Patrik Dufresne <ikus060@gmail.com>
|
|
I described the requirement in a most possible neutral way (hope this is OK) in the enhancement #418 , and would invite you to participate all to the discussion over there. My comments will be obviously less neutral and represent my own opinion :-) |
Also add a note in the developer documentation. CHG: setuptools is a runtime dependency for installation and tests so that version appears correctly instead of DEV, closes #305
CHG: setuptools is a runtime dependency for installation and tests so that version appears correctly instead of DEV, closes #305 * Add setuptools as runtime dependency to tox and setup.py also add a note in the developer documentation. * Limit wildcard to only repair rdiff-backup wheels and also limit what is being deployed
Fixes: rdiff-backup#305 Also extend autopkgtest to verify this.
Want to report a problem. I didn't check what wrong with the build.
Shows
rdiff-backup DEVThe text was updated successfully, but these errors were encountered: