Re: packaging django-rest-framework-filters

2018-12-07 Thread Wookey
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

2018-11-29 Thread Piotr O┼╝arowski
[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

2018-11-29 Thread Scott Kitterman
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

2018-11-29 Thread Thomas Goirand
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

2018-11-28 Thread Neil Williams
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

2018-11-28 Thread Wookey
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

2018-11-28 Thread Neil Williams
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

2018-11-25 Thread Wookey
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

2018-11-22 Thread Piotr O┼╝arowski
[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

2018-11-22 Thread Wookey
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

2018-11-21 Thread Thomas Goirand
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)