Re: Issues with using python37

[John Klos <john%ziaspace.com@localhost>]

> One is that pkg_rr should deal with pyNN- packages better.  There are
> I think at least two, maybe three parts to this:
>
>  A) For an installed package pyNN-foo or similar, extract NN and pass
>  it as a version variable into the make replace.  This will enable
>  pkg_rr, once such a package is selected, to replace it, in the case
>  where NN isn't default

This would work, but it wouldn't facilitate the move from Python27 to 37, 
which is what I think is going on here.

>  B) Either make the info used to denote packages be a pair of
>  PKGNAME/PKGPATH, or decide that if PKGNAME doesn't map to an installed
>  package, then it can be ignored.
>
>  C) The other is that make replace in general has a hard time for some
>  kinds of changes.  One example is moving entries from a package's
>  PLIST to the PLIST of a package that it (newly or already/still)
>  depends on.  Here, I don't think this is part of the problem, but it's
>  hard to be sure.

This is where a full delete of a package and several if not most 
dependencies, then a reinstall of the root package is necessary. I've run 
in to this, but it escapes my memory what required this.

> Reading the code and your log, I think the issue is that py37-expat
> got added to REPLACE_TODO, even though it isn't installed

Exactly. py27-expat was installed for devel/glib, and now devel/glib wants 
py37-expat.

> To test a theory that could lead to fixing B:
>
>  Try changing the abort on line 422 to an echo, or to error instead of
>  abort and use -k.  I am inclined to s/abort/error/ here, but I'd like
>  to hear how it goes.

This still stops with this error:

*** pkg_chk reports the following packages need replacing, but they are 
not installed: py37-dns

> To work around the issue, three suggestions
>
>  D) build and install py37-expat.  Set automatic=YES manually if you care
>  about that.
>
>  E) go to devel/glib2 and type make replace.  If you replace things in the
>  wrong order, more or less nothing terrible should happen -- you might
>  just build things more times than an optimal order would have.

This works, and I've already done this on a few machines without issues. 
However, it doesn't help on machines with lots of python packages, like 
this one:

RR> Tsorting dependency graph
*** pkg_chk reports the following packages need replacing, but they are 
not installed: py34-scandir
py37-argparse
py37-atomicwrites
py37-attrs
py37-dns
py37-iso8601
py37-linecache2
py37-mako
py37-more-itertools
py37-pathlib2
py37-pbr
py37-pip
py37-pluggy
py37-py
py37-scons
py37-setuptools
py37-setuptools_scm
py37-six
py37-subversion
py37-test
py37-traceback2
py37-unittest2
*** Please read the errors listed above, fix the problem,
*** then re-run pkg_rolling-replace to continue.


>  F) set up pbulk, build all your packages, remove and reinstall, and start
>  over in the brave new world of py37

That's certainly the long way around the proverbial barn, and it would 
certainly work, but for now I'd like to examine easier ways to upgrade 
packages from python27 to 37, as it'd likely help others, too.

> I would do E.

E is good for most of my machines, but for that machine which lists 22 
packages which are "not installed", hardly.

On the other hand, I could make replace all 22 of them with a simple 
script. But what's the best fix to tell other pkgsrc users?

Thanks,
John