Bug#962574: ITP: dephell -- project management for Python
Package: wnpp Severity: wishlist Owner: Nicholas D Steeves Package name: dephell Version : 0.8.3 Upstream Author : Gram URL : http://www.example.org/ License : MIT (declared, but probably Expat) Programming Lang: Python Description : project management for Python DepHell Project management for Python * Format agnostic: supports setup.py, requirements.txt, Pipfile, poetry. DepHell converts between them at any time. * All-in-one-solution: manage dependencies, virtual environments, tests, CLI tools, packages; generate configs; show licenses for dependencies; assist with security audits; get download statistics from PyPI; search packages, and much more. * Smart dependency resolution: manages dependencies, resolves, and enables locking of dependencies that pip missed. * Asyncio based: optimised network and filesystem requests. * Multiple environments: facilitates the use of multiple environments per project. * Release tools: provides build, test, version upgrade, and upload helpers. When I imported the latest version of Fissix, I discovered that it had migrated to pyproject.toml. I asked #debian-python about what the status of Debian tooling is for this format, and had a good discussion with ScottK. My immediate motivation for packaging DepHell is to convert Fissix's pyproject.toml to setup.py to expedite the completion of its ITP. I also wonder if it might be useful within a dh_python context. It's highly likely this software will be useful to the general Python developer community, and I plan to maintain it in either the DPMT or PAPT, as appropriate. Please comment on this! If anyone on the DPMT or PAPT would like to comaintain this package, please let me know, and I'll add you to Uploaders without delay. I will require a sponsor for the initial upload. Regards, Nicholas
Re: SETUPTOOLS_SCM_PRETEND_VERSION trick : how to use it in autopkgtest?
On Tue, 09 Jun 2020 at 11:50:02 +0200, Julien Puydt wrote: > (1) during the autopkgtest run, we're not in the package source tree, > are we? So there should be no access do d/changelog? The cwd of each test is guaranteed to be the root of the source package, which will have been unpacked but not built. However note that the tests must test the installed version of the package, as opposed to programs or any other file from the built tree. — https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst I've found that a lot of the time, what makes most sense is to gather the information you need from the source tree, copy the files you need from the source tree into a temporary directory, cd into the temporary directory, and do the rest of your testing there. This avoids things like Python's default "add the script's directory to sys.path" behaviour accidentally picking up the version of the library that's in the source package, which would result in not testing the installed copy as required. For example, src:python-mpd does this. Another way to get a similar result is to install the tests as part of the binary packages, cd into an empty temporary directory, and run them from the installed location. src:tap.py does this (the tests are small, so they're just included in the main binary package) and so does src:dbus-python (the tests are larger and have non-trivial dependencies, so they're a separate binary package). autopkgtest guarantees that $AUTOPKGTEST_TMP is an empty temporary directory, or you can make your own with mktemp -d or similar, or you can use a tool like ginsttest-runner (aka gnome-desktop-testing-runner, in the gnome-desktop-testing package) that does it for you. smcv
Re: SETUPTOOLS_SCM_PRETEND_VERSION trick : how to use it in autopkgtest?
Hi,
Le mardi 09 juin 2020 à 10:35 +0200, Ondrej Novy a écrit :
> po 8. 6. 2020 v 17:22 odesílatel Julien Puydt > napsal:
> > I know about the SETUPTOOLS_SCM_PRETEND_VERSION trick when it is
> > used
> > in d/rules :
> >
> > include /usr/share/dpkg/pkg-info.mk
> > export SETUPTOOLS_SCM_PRETEND_VERSION=$(DEB_VERSION_UPSTREAM)
>
> dh-python do this automatically when python{,3}-setuptools-scm is in
> B-D.
Oh, so in fact, the only package which should do that in its d/rules
should be setuptools-scm itself, then ?
> > I got around by turning d/tests/upstreamtestsuite to:
> >
> > #!/bin/sh
> > set -e
> > SETUPTOOLS_SCM_PRETEND_VERSION=0.0.0 python3 setup.py test 2>&1
> >
> > which worked because in fact the tests don't care about the
> > version.
>
> you can use "dpkg-parsechangelog -SVersion" or include
> /usr/share/dpkg/pkg-info.mk + $DEB_VERSION_UPSTREAM here too.
There are several things I don't understand there:
(1) during the autopkgtest run, we're not in the package source tree,
are we? So there should be no access do d/changelog?
(2) including pkg-info.mk is for makefiles, so not available there, and
dpkg-parsechangelog -SVersion will give me the full Debian version, not
just upstream's.
Thanks,
JP
Re: SETUPTOOLS_SCM_PRETEND_VERSION trick : how to use it in autopkgtest?
H,
po 8. 6. 2020 v 17:22 odesílatel Julien Puydt
napsal:
> Hi,
>
> I know about the SETUPTOOLS_SCM_PRETEND_VERSION trick when it is used
> in d/rules :
>
> include /usr/share/dpkg/pkg-info.mk
> export SETUPTOOLS_SCM_PRETEND_VERSION=$(DEB_VERSION_UPSTREAM)
>
dh-python do this automatically when python{,3}-setuptools-scm is in B-D.
> I got around by turning d/tests/upstreamtestsuite to:
>
> #!/bin/sh
> set -e
> SETUPTOOLS_SCM_PRETEND_VERSION=0.0.0 python3 setup.py test 2>&1
>
> which worked because in fact the tests don't care about the version.
>
you can use "dpkg-parsechangelog -SVersion" or include /usr/share/dpkg/
pkg-info.mk + $DEB_VERSION_UPSTREAM here too.
--
Best regards
Ondřej Nový
