On 8/30/19 3:45 PM, Gordon Messmer wrote:
> On 8/29/19 1:54 PM, Robert Moskowitz wrote:
>>
>> Will this automagically change on Jan 1, 2020?
>
>
> No, but it will be changed in Fedora 31:
> https://fedoraproject.org/wiki/Changes/Python_means_Python3
>
>
>> Is there a way to get it changed now and see what is in trouble
>> (though there is very little python that I know I am using).
>
>
> If you're using only packaged python applications, everything should
> be fine. If you have your own in /usr/local or some other local root
> directory, you will probably want to check for newer versions and
> re-install them. You can do that now, and you should use either the
> "python2" or "python3" command when doing so.
There are now many more python3 than python2 packages:
$ dnf list python2-\* > python2-rpm.list
$ dnf list python3-\* > python3-rpm.list
$ wc -l python*.list
899 python2-rpm.list
2648 python3-rpm.list
3547 total
Some common packages (matplotlib) have newer versions for
python3 that for python2.
The only non Fedora packaged python app I am running is xml2rfc.
The changelog indicates support for python 2 and 3. The docs
mention using WeasyPrint to generate PDF's, -- also appears not
to have fedora packages.
You
can use:
$ python3 -m pip install --user xml2rfc
[...]
Successfully installed certifi-2019.6.16 chardet-3.0.4
google-i18n-address-2.3.5 html5lib-1.0.1 idna-2.8
intervaltree-3.0.2 kitchen-1.2.6 lxml-4.4.1
pycountry-19.8.18 pyflakes-2.1.1
requests-2.22.0 sortedcontainers-2.1.0 urllib3-1.25.3
webencodings-0.5.1 xml2rfc-2.25.0
As you see, this pulls in a bunch of packages, many of
which should be in the list of python3 packages. For
some use cases it would be better to use as many
of the distro packages as possible so you don't have
to track updates on all those packages.
This is what the IETF community tends to use to create Internet Drafts.
Many of us prefer writing in xml. Many prefer Markdown and have an app
that converts their .md to .xml. There are a few (some Chinese) that
still use Word and create .txt which then needs cleanup. Then there are
those that insist that they NEED pdf images for their RFCs (but they are
REQUIRED to also generate ascii graphics and .txt versions).
Fun for all. Your RFCs in the making. Like any sausage, you probably
don't want to know what we put into them.
:)
If xml2rfc screws up you will probably notice right away -- what keeps
me up at night are the calculations where there is no easy way to detect
an error, so you really have to watch for bug reports on key packages.