On Sun, Feb 06, 2022 at 04:46:53PM +, Stefano Rivera wrote:
> Hi Julian (2022.02.06_12:19:54_+)
> > In the couple of cases I've looked at so far, it is due to the
> > upstream version using use_scm_version in setup.py. This works fine
> > for a version that is in a Git repository, but it d
> Or export SETUPTOOLS_SCM_PRETEND_VERSION.
> https://github.com/pypa/setuptools_scm#environment-variables
>
> pybuild does this for you.
i dont remember the exact details, but sometimes that doesnt work:
even just building the source package (which runs dh clean, which
invokes setup.py clean) the
Hi Julian (2022.02.06_12:19:54_+)
> In the couple of cases I've looked at so far, it is due to the
> upstream version using use_scm_version in setup.py. This works fine
> for a version that is in a Git repository, but it doesn't work for
> Debian packages, as the Git version lookup fails. So
On Sat, Feb 05, 2022 at 04:42:57PM -0500, Sandro Tosi wrote:
> > The test for this bug (and it should probably be recorded as an error,
> > not just a warning, as no Python package should have a version number
> > of 0.0.0)
>
> what exactly is the problem that would make it an 'error'?
When a pac
> The test for this bug (and it should probably be recorded as an error,
> not just a warning, as no Python package should have a version number
> of 0.0.0)
what exactly is the problem that would make it an 'error'?
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wi
Package: lintian
Version: 2.111.0
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org
I just ran into several Python packages that install modules with
version number 0.0.0 because of some issue with their setup.py
scripts. I just did the following on my testing system:
lz4cat
/var/
6 matches
Mail list logo
