On 2020/02/20 10:12, Kurt Mosiejczuk wrote:
> > There is a possible future direction I've been considering of moving py2
> > ports from "unflavoured" to "FLAVOR=python2" (and possibly splitting
> > python3 into multiple versions e.g. python37/python38 as we do with ruby).
> > I'm unsure if it's worthwhile at the moment, but this method of converting
> > to py3-only at least doesn't get in the way of doing that later.
>
> I like the FLAVOR=python2. I'm a little wary of the python37/python38
> thing. It will introduce a *lot* of churn each time we introduce a
> new python 3.x version to the tree or when we retire one.
Me too, but other things being equal I'd prefer not to make changes
now that would interfere with it in case we did want to change it later.
(For example if we generally have things setup where py3=unflavoured,
that *would* get in the way).
+ easier to test new python releases
- more work bumping revision in dependencies and managing category Makefiles
- brings back the MODPY_BIN_SUFFIX problem that otherwise would be helped
by moving to 3-only
On 2020/02/20 16:25, Björn Ketelaars wrote:
> Sounds like a plan...
>
> What about lines in Makefile like the one below. Does it make sense to
> keep them around? There is no need to add a suffix to scripts in the
> case of py3-only.
>
> mv ${PREFIX}/bin/$i{,${MODPY_BIN_SUFFIX}}
exactly, getting rid of these is a big win :)
For ports containing scripts which remain as py2+py3 (the most obvious
example being py-sphinx, but there are many others) I'd like to have py3
as the "unsuffixed" version, but haven't figured out how to do this yet ;)
> > Obviously there are currently a number of py3-only ports which should end
> > up using the same flavour scheme (and dependency lines to fix), if there are
> > not objections I can either review diffs or take care of those myself.
>
> I'm not sure what is needed for ports that already made the jump from
> py2/py3 to py3-only (e.g. www/jupyter-notebook). More specific: these
> ports already do some funky PLIST and quirks stuff. Do these ports need
> special attention?
jupyter-notebook is a bit of a special case as it's more "end-user software"
rather than a module (which is acknowledged by not using the py- prefix on the
package name).
In other cases (some which come to mind are flake8 and beets), this type
of port doesn't normally support using multiple python versions via
flavours, jupyter-notebook is (was) special in that regard. So I think
it's ok to keep that as-is.
