Re: packaging django-rest-framework-filters
On 2018-11-22 08:59 +0100, Thomas Goirand wrote: > On 11/22/18 6:02 AM, Wookey wrote: > > Also related: I've updated drf-extensions to 0.4 (from the current > > 0.3.1), as that is needed for lava, and fixes > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865851 > > > > What I'm not quite sure about is if there is any reason _not_ to > > update this package. It has no reverse dependencies so I presume this > > is a good idea and I should just get on with it? would a 10-day NMU be > > appropriate? > > If you join the team, I see no reason why you couldn't do the upgrade > yourself indeed, especially if you do a 10-day NMU on it. OK. Can you/someone sign me up to the team please? (asking here seems to the mechanism, according to https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin I have read and accept: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst (although this maintaining packages with git malarkey is entirely new to me - I'll try and get it right). It looks very complicated in comparison to making a debian package and uploading it. Then I'll do this drf-extensions update as a team upload. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: packaging django-rest-framework-filters
[Scott Kitterman, 2018-11-29]
> dh-python already doesn't use upstream version requirements when
> automatically
> extracting dependencies, so you have to check those yourself regardless of
> how
> you do it. This design decision was based on generally poor experiences with
> the accuracy of upstream version descriptions (using exact version
> requirements is very common in the upstream Python community and that
> generally isn't supportable in Debian).
actually dh_python{2,3} extracts it, but only if package maintainer of
given module claims it is sane (via PEP386 tag in pydist file)
f.e. I consider Mako's versioning sane, so I added PEP386 tag to pydist
file in src:mako and now all packages that have "Mako>=1.0.3" in setup.py's
install_requires AKA requires.txt (do not confuse with requirements.txt)
will get the dependency.
Another way to get versioned dependency is to add version restriction in
Build-Depends (but that has to be updated each time upstream changes it,
it needs to be done for build tests anyway). This is only a bit better
than hardcoding it in Depends, though.
Note that it doesn't cover the "I tested it with latest Mako so lets
require latest one in install_requires" case, so I'm not promoting
PEP386 that much (IMO package maintainers have to translate minimum
required versions into proper Build-Depends dependencies by hand for
now)
--
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: packaging django-rest-framework-filters
On Thursday, November 29, 2018 11:44:44 AM Neil Williams wrote: > On Thu, 29 Nov 2018 11:41:40 +0100 > > Thomas Goirand wrote: > > On 11/28/18 5:51 PM, Neil Williams wrote: > > > I'd expect at least python3-django to be in that list. Could be an > > > upstream bug in their setup.py > > > > From my experience, it's always best to explicitly express the > > dependencies manually and not rely on upstream setup.py to do things > > correctly. Often, it doesn't. > > That does have the weakness that if there are changes in the version > requirements, those won't get picked up as easily, adding to the > maintenance workload. I do think it's worth reporting such issues to > upstream. (I'd certainly want it reported for the projects where I am > part of upstream.) dh-python already doesn't use upstream version requirements when automatically extracting dependencies, so you have to check those yourself regardless of how you do it. This design decision was based on generally poor experiences with the accuracy of upstream version descriptions (using exact version requirements is very common in the upstream Python community and that generally isn't supportable in Debian). Scott K signature.asc Description: This is a digitally signed message part.
Re: packaging django-rest-framework-filters
On 11/28/18 5:51 PM, Neil Williams wrote: > I'd expect at least python3-django to be in that list. Could be an > upstream bug in their setup.py >From my experience, it's always best to explicitly express the dependencies manually and not rely on upstream setup.py to do things correctly. Often, it doesn't. Cheers, Thomas Goirand (zigo)
Re: packaging django-rest-framework-filters
On Wed, 28 Nov 2018 14:38:20 + Wookey wrote: > On 2018-11-28 08:58 +, Neil Williams wrote: > > On Mon, 26 Nov 2018 04:05:05 + > > Wookey wrote: > > > > > On 2018-11-22 08:59 +0100, Thomas Goirand wrote: > > > > On 11/22/18 6:02 AM, Wookey wrote: > > > > > > I guess djangorestframework-filters is > > > clearer, and closer to upstream so people can find it. I'll go > > > with that unless someone says the drf-* names are a better plan. > > > > > > OK. I've made a new package (djangorestframework-filters), which > > > seems OK. (actually I've made 2 (see below)) > > > > > > I'm not a member of the modules team, so can't follow the > > > instructions to make a salsa project under the python-team banner > > > (https://wiki.debian.org/Python/GitPackaging) > > > > > > I'll put it under wookey for now. > > > > > > Also, the latest release is 0.10.0.post0, which says it's > > > compatible with: > > > * **Python**: 2.7 or 3.3+ > > > * **Django**: 1.8, 1.9, 1.10, 1.11 > > > * **DRF**: 3.5, 3.6 > > > > djangorestframework lists "Breaking changes" in the release notes > > for 3.8, so this looks like an incompatibility with what's already > > in Debian. > > > > https://github.com/encode/django-rest-framework/releases/tag/3.8.0 > > > > It might be worth testing whether 0.10.0.post0 or another release of > > django-rest-framework-filters between that and 1.0.0dev0 is actually > > fine with djangorestframework 3.8 - at least at a unit test level. > > Milosz and I are doing just that. > > It would be great if you could check whether these packages work OK > with lava or not as that's at least one datapoint: > http://wookware.org/software/repo/pool/main/d/drf-extensions/python3-djangorestframework-extensions_0.4.0-1_all.deb A bit surprised to see that this binary only depends on: Depends: python3-djangorestframework, python3:any I'd expect at least python3-django to be in that list. Could be an upstream bug in their setup.py - relying only on the indirect dependency via python3-djangorestframework is a bit odd/lazy to me. The package does directly import modules from django, it doesn't exclusively import from django-restframework, not least in it's own settings.py. > http://wookware.org/software/repo/pool/main/d/djangorestframework-filters/python3-djangorestframework-filters_0.10.2.post0-1_all.deb For comparison: Depends: python3-django, python3-django-filters, python3-djangorestframework, python3:any So I can install both of those packages ok on buster, I can run the existing LAVA unit tests without failures and I can browse the localhost LAVA UI (including REST API) with those installed. However, that only a minimal datapoint - the REST API doesn't yet have code to use the support available from these packages. It's basically only an install test, not execution. I've successfully imported the modules into the django developer shell using lava-server manage.py shell, so that bit works too. If there are particular tests that would be useful, let me know. > > > However the version of DRF in testing is now 3.8, and python 3.6 > > > so perhaps it's better to upload the upcoming v1.0.0.dev0: > > > * **Python**: 3.4, 3.5, 3.6 > > > * **Django**: 1.11, 2.0, 2.1b1 > > > * **DRF**: 3.8 > > > * **django-filter**: 2.0 > > > > > > But the version of django-filter in debian is 1.1.0, so at first > > > glance neither of these versions will work with the components > > > available. > > > > > > I'd normally upload the last released version, i.e. 0.10.2.post0, > > > but I'm not sure how these interactions with versions of > > > djangorestframework and django-filter work. Any advice or shall I > > > work this out with upstreams? > > > > django-filters has a new upstream 2.0 but a migration guide has been > > published for that: > > > > https://django-filter.readthedocs.io/en/master/guide/migration.html#migrating-to-2-0 > > > > Cheers for that link > > > So it's likely that at least some reverse dependencies would be > > broken by django-filters version 2.0. > > As you say - if we have to go to django-filters 2.0, then things > probably get complicated (too complicated for buster). > > Wookey > -- > Principal hats: Linaro, Debian, Wookware, ARM > http://wookware.org/ -- Neil Williams h...@codehelp.co.uk pgpU0Tf_qkLds.pgp Description: OpenPGP digital signature
Re: packaging django-rest-framework-filters
On 2018-11-28 08:58 +, Neil Williams wrote: > On Mon, 26 Nov 2018 04:05:05 + > Wookey wrote: > > > On 2018-11-22 08:59 +0100, Thomas Goirand wrote: > > > On 11/22/18 6:02 AM, Wookey wrote: > > > > I guess djangorestframework-filters is > > clearer, and closer to upstream so people can find it. I'll go with > > that unless someone says the drf-* names are a better plan. > > > > OK. I've made a new package (djangorestframework-filters), which > > seems OK. (actually I've made 2 (see below)) > > > > I'm not a member of the modules team, so can't follow the instructions > > to make a salsa project under the python-team banner > > (https://wiki.debian.org/Python/GitPackaging) > > > > I'll put it under wookey for now. > > > > Also, the latest release is 0.10.0.post0, which says it's compatible > > with: > > * **Python**: 2.7 or 3.3+ > > * **Django**: 1.8, 1.9, 1.10, 1.11 > > * **DRF**: 3.5, 3.6 > > djangorestframework lists "Breaking changes" in the release notes for > 3.8, so this looks like an incompatibility with what's already in > Debian. > > https://github.com/encode/django-rest-framework/releases/tag/3.8.0 > > It might be worth testing whether 0.10.0.post0 or another release of > django-rest-framework-filters between that and 1.0.0dev0 is actually > fine with djangorestframework 3.8 - at least at a unit test level. Milosz and I are doing just that. It would be great if you could check whether these packages work OK with lava or not as that's at least one datapoint: http://wookware.org/software/repo/pool/main/d/drf-extensions/python3-djangorestframework-extensions_0.4.0-1_all.deb http://wookware.org/software/repo/pool/main/d/djangorestframework-filters/python3-djangorestframework-filters_0.10.2.post0-1_all.deb > > However the version of DRF in testing is now 3.8, and python 3.6 so > > perhaps it's better to upload the upcoming v1.0.0.dev0: > > * **Python**: 3.4, 3.5, 3.6 > > * **Django**: 1.11, 2.0, 2.1b1 > > * **DRF**: 3.8 > > * **django-filter**: 2.0 > > > > But the version of django-filter in debian is 1.1.0, so at first > > glance neither of these versions will work with the components > > available. > > > > I'd normally upload the last released version, i.e. 0.10.2.post0, but > > I'm not sure how these interactions with versions of > > djangorestframework and django-filter work. Any advice or shall I work > > this out with upstreams? > > django-filters has a new upstream 2.0 but a migration guide has been > published for that: > > https://django-filter.readthedocs.io/en/master/guide/migration.html#migrating-to-2-0 Cheers for that link > So it's likely that at least some reverse dependencies would be broken > by django-filters version 2.0. As you say - if we have to go to django-filters 2.0, then things probably get complicated (too complicated for buster). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: packaging django-rest-framework-filters
On Mon, 26 Nov 2018 04:05:05 + Wookey wrote: > On 2018-11-22 08:59 +0100, Thomas Goirand wrote: > > On 11/22/18 6:02 AM, Wookey wrote: > > I guess djangorestframework-filters is > clearer, and closer to upstream so people can find it. I'll go with > that unless someone says the drf-* names are a better plan. > > OK. I've made a new package (djangorestframework-filters), which > seems OK. (actually I've made 2 (see below)) > > I'm not a member of the modules team, so can't follow the instructions > to make a salsa project under the python-team banner > (https://wiki.debian.org/Python/GitPackaging) > > I'll put it under wookey for now. > > Also, the latest release is 0.10.0.post0, which says it's compatible > with: > * **Python**: 2.7 or 3.3+ > * **Django**: 1.8, 1.9, 1.10, 1.11 > * **DRF**: 3.5, 3.6 djangorestframework lists "Breaking changes" in the release notes for 3.8, so this looks like an incompatibility with what's already in Debian. https://github.com/encode/django-rest-framework/releases/tag/3.8.0 It might be worth testing whether 0.10.0.post0 or another release of django-rest-framework-filters between that and 1.0.0dev0 is actually fine with djangorestframework 3.8 - at least at a unit test level. > However the version of DRF in testing is now 3.8, and python 3.6 so > perhaps it's better to upload the upcoming v1.0.0.dev0: > * **Python**: 3.4, 3.5, 3.6 > * **Django**: 1.11, 2.0, 2.1b1 > * **DRF**: 3.8 > * **django-filter**: 2.0 > > But the version of django-filter in debian is 1.1.0, so at first > glance neither of these versions will work with the components > available. > > I'd normally upload the last released version, i.e. 0.10.2.post0, but > I'm not sure how these interactions with versions of > djangorestframework and django-filter work. Any advice or shall I work > this out with upstreams? django-filters has a new upstream 2.0 but a migration guide has been published for that: https://django-filter.readthedocs.io/en/master/guide/migration.html#migrating-to-2-0 So it's likely that at least some reverse dependencies would be broken by django-filters version 2.0. $ apt-cache rdepends python3-django-filters python3-django-filters Reverse Depends: python3-djangorestframework python3-djangorestframework-gis python3-djangorestframework python3-djangorestframework-gis It may be too late to get things like this untangled before the buster release. Dabbling with django-filters 2.0 now could end up causing removal of packages which work just fine with the current set. Looks to me like django-filters 2.0 needs to be handled in bullseye. -- Neil Williams h...@codehelp.co.uk pgp6s2uJupV1j.pgp Description: OpenPGP digital signature
Re: packaging django-rest-framework-filters
On 2018-11-22 08:59 +0100, Thomas Goirand wrote: > On 11/22/18 6:02 AM, Wookey wrote: I guess djangorestframework-filters is clearer, and closer to upstream so people can find it. I'll go with that unless someone says the drf-* names are a better plan. OK. I've made a new package (djangorestframework-filters), which seems OK. (actually I've made 2 (see below)) I'm not a member of the modules team, so can't follow the instructions to make a salsa project under the python-team banner (https://wiki.debian.org/Python/GitPackaging) I'll put it under wookey for now. Also, the latest release is 0.10.0.post0, which says it's compatible with: * **Python**: 2.7 or 3.3+ * **Django**: 1.8, 1.9, 1.10, 1.11 * **DRF**: 3.5, 3.6 However the version of DRF in testing is now 3.8, and python 3.6 so perhaps it's better to upload the upcoming v1.0.0.dev0: * **Python**: 3.4, 3.5, 3.6 * **Django**: 1.11, 2.0, 2.1b1 * **DRF**: 3.8 * **django-filter**: 2.0 But the version of django-filter in debian is 1.1.0, so at first glance neither of these versions will work with the components available. I'd normally upload the last released version, i.e. 0.10.2.post0, but I'm not sure how these interactions with versions of djangorestframework and django-filter work. Any advice or shall I work this out with upstreams? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Re: packaging django-rest-framework-filters
[Wookey, 2018-11-22] > No advice on best way to start a python packaging template? # apt install pypi2deb $ py2dsp djangorestframework-filters source package will be available in ./result/ (change it with --root) you can add '--profile dpmt' if you want to maintain it inside DPMT -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: packaging django-rest-framework-filters
On 2018-11-22 08:59 +0100, Thomas Goirand wrote: > On 11/22/18 6:02 AM, Wookey wrote: No advice on best way to start a python packaging template? > > And it looks like it should be called src:drf-filters > > binary:python3-djangoresetframework-filters to fit in with naming > > conventions of related packages/python team (even though upstream is > > 'django-rest-framework-filters'). Right? > > The binary package name is right, though there's no convention for the > source package naming. "drf-filters" doesn't feel very descriptive to me > though. I agree, but I took it from drf-extensions -> python3-djangorestframework-extensions drf-generators -> python3-djangorestframework-generators drf-haystack -> python3-djangorestframework-haystack on the other hand there is: djangorestframework-gis -> python3-djangorestframework-gis I don't care which is used. I guess djangorestframework-filters is clearer, and closer to upstream so people can find it. I'll go with that unless someone says the drf-* names are a better plan. > > Also related: I've updated drf-extensions to 0.4 (from the current > > 0.3.1), as that is needed for lava, and fixes > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865851 > > > > What I'm not quite sure about is if there is any reason _not_ to > > update this package. It has no reverse dependencies so I presume this > > is a good idea and I should just get on with it? would a 10-day NMU be > > appropriate? > > If you join the team, I see no reason why you couldn't do the upgrade > yourself indeed, especially if you do a 10-day NMU on it. So I need to join the team to do anything in the salsa repos? I don't claim any real python extertise (I can just about read it - I try to avoid writing it as I'm a bash, perl and C person). I would prefer to sort this out to a decent standard and then hand it over the python team for maintenance, but I can join up as a minor conributor if that works better. It occurs to me that you probably prefer me to do this as a branch in the drf-extensions salsa repo, rather than a simple NMU? I prefer the latter as I know how to do that (sbuild+dupload), but if I have the permissions I can have a go at this newfangled git-pq + salsa stuff. I presume that'll be less work for you guys and I suppose I'll learn something :-) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: packaging django-rest-framework-filters
On 11/22/18 6:02 AM, Wookey wrote: > And it looks like it should be called src:drf-filters > binary:python3-djangoresetframework-filters to fit in with naming > conventions of related packages/python team (even though upstream is > 'django-rest-framework-filters'). Right? The binary package name is right, though there's no convention for the source package naming. "drf-filters" doesn't feel very descriptive to me though. > Also related: I've updated drf-extensions to 0.4 (from the current > 0.3.1), as that is needed for lava, and fixes > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865851 > > What I'm not quite sure about is if there is any reason _not_ to > update this package. It has no reverse dependencies so I presume this > is a good idea and I should just get on with it? would a 10-day NMU be > appropriate? If you join the team, I see no reason why you couldn't do the upgrade yourself indeed, especially if you do a 10-day NMU on it. Cheers, Thomas Goirand (zigo)
