Date: Thu, 14 Mar 2019 15:12:41 -0400
From: Drew DeVault <sir@cmpwn.com>
To: Natanael Copa <ncopa@alpinelinux.org>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] Normalizing Python packages in aports
Message-ID: <20190314191241.GF1544@homura.localdomain>
References: <20190306212501.GD2800@cirno.localdomain>
 <20190314112413.29dd9816@ncopa-desktop.copa.dup.pw>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190314112413.29dd9816@ncopa-desktop.copa.dup.pw>

Thanks for the feedback!

On 2019-03-14 11:24 AM, Natanael Copa wrote:
> > # Maintainer: Joe Bloe <joe@example.org>
> > pkgname=py-alpine-name
> 
> What do we for python2 only modules?

Delete them.

> What do we when python4 arrives? should we start plan for that already
> now? Does it make sense to use pkgname=py3-alpine-name?
> -%<-
> I think we should already now start think how to deal with python 4,
> whenever that comes.

Nack. I will eat my hat (and volunteer for another overhaul effort) if
another backwards-incompatible Python shitstorm happens in the next 25
years.

> I dont really like the variable name "_pkgname" as it does not really
> say anything. I think something like "_pypiname", "_pyname" or
> "_upstream_name" is better.

+1 for _pyname.

> we should use https:// in our example.
> -%<-
> the ${_pkgname:0:1} expansion is a bash extension which happens to be
> supported by busybox ash. We do use some of those, but it would be
> better to avoid if possible.
> -%<-
> We should make sure all the direct runtime dependencies are specified
> in the makedepends, or the build server may not be able to detect that
> the dependencies needs to be built first.

Ack

> > makedepends="py-setuptools"
> 
> I think this is somewhat tricky, because the real dependency here is
> py3-setuptools which gets pulled in indirectly. I would prefer that we
> use the direct dependency instead of rely that the indirect
> dependencies will be done correctly.
> -%<-
> I would prefer that we use the direct dependency instead of rely that
> the indirect dependencies will be done correctly.

Using `makedepends="py3-setuptools"` presents a problem as well, for
Python 2 deprecation/removal. If we rename py3-* to py-*, we will have
to go through and fix all of these later. If we use meta-packages, this
problem with fix itself when Python 2 is removed, and I'd err on the
side of spot-fixing weirdness until then.

> > prepare() {
> > 	cp -r "$builddir" "$builddir"-py3
> 
> setuptools does not support out-of-tree builds?

Not without hacks, I'm afraid. I'm not too torn up about it since we'll
want to be leaving Python 2 behind anyway.

> > _py() {
> >	python="$1"
> 
> we need 'local' here.

local is also a bash extension. It's undefined behavior in POSIX shell.

> There is an optional way to do it, without the _py2 and _py3 functions:
> -%<-
> 
> But I suppose using _py2 and _py3 functions makes things more readable.

Is doing it without the _py2 and _py3 functions desirable if it makes
things less readable?

> > Another issue we'll have to face soon enough is Python 2 end-of-life. Do
> > we want to address this at the same time? I think the best balance of
> > conservatism and speedy removal of python 2 would be:
> > 
> > - Stop adding new python 2 packages to aports
> > - As we normalize existing packages, drop python 2 if it's easy, or make
> >   a note if not
> > - Make case-by-case judgement calls on the more difficult packages,
> >   based on the upstream's progress/amicability towards a python 3 port.
> >   Upstreams which are unwilling to port to python 3 should probably just
> >   be dropped.
> 
> I think those are good suggestions.
> 
> I think removing python2 completely may be tricky and I support doing
> it in small steps. We should work in that direction.

I've written this up into the wiki page, along with incorporating the
rest of your feedback.

https://wiki.alpinelinux.org/w/index.php?title=Python_package_policies&type=revision&diff=15799&oldid=15755

Another question: how should we structure this work? I would appreciate
volunteers (I think there already were some on IRC) to participate and
help with code reviews. We probably ought to work out-of-tree and
periodically request-pull our work into aports.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---