Mail archive

Re: [alpine-devel] Normalizing Python packages in aports

From: Drew DeVault <>
Date: Thu, 14 Mar 2019 15:12:41 -0400

Thanks for the feedback!

On 2019-03-14 11:24 AM, Natanael Copa wrote:
> > # Maintainer: Joe Bloe <>
> > 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

> 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.


> > 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.

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.

Received on Thu Mar 14 2019 - 15:12:41 UTC