[moin-user] Moin no longer in debian stable?

[Paul Boddie]

On Thursday, 7 October 2021 02:00:35 CEST Lukasz Szybalski wrote:
> Paul,
> Thank you for your comments.

No problem! Note that I am just another observer with regard to Moin 2, so 
this is as much a voyage of discovery for me as it is for you.

> To explore the 2.0 upgrade, (while I'm not familiar with its planned or
> completed goals); does the moin 2.0 include "upgrade" scripts to convert
> existing 1.9 repo's to 2.0 repo's assuming python 2 is no longer available?

It looks like it. Conveniently, looking at the current history on GitHub, the 
following appears:

import19 should offer choice of output converters, fixes #1122

Which suggests that there are indeed converters. And I missed that Moin 2 
seems to support Python 3, which is not particularly prominent from the wiki 
page. (It says "master branch: Python 3.5+" three quarters of the way down the 
page.)

> If the upgrade scripts are there and the conversion process is somewhat
> seamless, then to unify development and community I would say "for long
> term" it might be more beneficial. But if the 2.0 is not backward
> compatible aka does not contain an upgrade process, then that might be
> challenging.

I am starting to think that with Python 3 compatibility, Moin 2 should be the 
emphasis of any real effort, given that converting Moin 1.9 to Python 3 would 
be the tedious chore that it was everywhere else in the Python ecosystem 
(thanks to the general mismanagement of the language roadmap).

So, I looked at Moin 2 again, and found a few things out...

Firstly, getting started could be better documented. The wiki page is not 
helpful here, nor is the README.rst file on GitHub. But there is the Sphinx 
documentation [1]:

https://moin-20.readthedocs.io/en/latest/

Specifically, this:

https://moin-20.readthedocs.io/en/latest/admin/install.html#installation-for-developers

Somewhere, the requirements for going any further will probably mention the 
need for venv and pip, although not prominently (you need to look at the 
quickinstall.py program's docstring), so given the Debian context, let me note 
this command to be somewhat helpful:

sudo apt-get install python3-venv python3-pip

Now, the quickinstall.py program will fail without venv and pip, not even 
showing any help text (which should appear if you put "help" after the program 
name on the command line), but it will also keep failing if it failed the 
first time...

"""
Traceback (most recent call last):
  File "./quickinstall.py", line 794, in <module>
    choice = 'cmd_%s' % args[1]
IndexError: list index out of range
"""

So, do this to try and remedy that:

rm activate m

I nevertheless found that the program will complain about an absence of "pip" 
in the log. [2] If we're pursuing a Python 3 strategy, we need pip3 on Debian. 
The quickinstall.py program is explicitly a Python 3 program, so I went 
through the program and parameterised it to take a common executable name for 
pip, introducing "pip3" as the value of this parameter. [3]

Cleaning up and running the program again got me lots of complaints about 
packages not building:

"""
  Running setup.py bdist_wheel for Flask-Script: started
  Running setup.py bdist_wheel for Flask-Script: finished with status 'error'
  Complete output from command /home/paulb/Software/Python/moin-2.0/moin-venv-
python3/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-
install-inu3e504/Flask-Script/setup.py';f=getattr(tokenize, 'open', open)
(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, 
__file__, 'exec'))" bdist_wheel -d /tmp/pip-wheel-ik38pfch --python-tag cp37:
  usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: -c --help [cmd1 cmd2 ...]
     or: -c --help-commands
     or: -c cmd --help

  error: invalid command 'bdist_wheel'

  ----------------------------------------
  Failed building wheel for Flask-Script
  Running setup.py clean for Flask-Script
"""

And so on, ending with warnings about mismatching setuptools versions:

"""
ERROR: setuptools==40.8.0 is used in combination with setuptools_scm>=6.x

Your build configuration is incomplete and previously worked by accident!
"""

The problem with this kind of thing is that you probably have to be the person 
who did all this Python packaging to understand what you did wrong. [4] I 
didn't really find a working remedy for the "bdist_wheel" issue: random people 
on the Internet suggest all sorts of "smash all the buttons" remedies 
involving the wheel package, setup.py, upgrading pip, and so on.

What initially "worked" for me was this:

pip3 install --upgrade pip

But because this puts a new version in my ~/.local directory hierarchy, I then 
needed to make sure that the full path to this separate pip3 program was given 
as the parameter I added to the quickinstall.py program. Still, the setuptools 
error remained, and I also got a complaint about "compile_catalog" not being 
supported.

(I then got into all sorts of other problems with regard to the .local 
directory connected to the idiocy of various Linux desktop developers, but let 
me save the rants for the footnotes.)

And so, I will leave things there for today, given that I also want to spend 
some of my spare time on other things, and also that this starts to resemble 
less attractive things about my day job. I have probably overlooked something 
here, but not being immersed in this project, I feel that things could be a 
bit more obvious.

But I hope that my moaning has indicated some areas where obstacles might be 
removed so that more people can investigate the presumably good stuff beyond 
those obstacles.

Paul

Footnote rants:

[1] Sphinx?! Still, unlike many of the projects whose documentation I find on 
Read The Docs these days, at least there is quite a bit of it here. But I 
thought that wikis were good for documentation and that is why we are using 
Moin, along with the nicer syntax than the overly cute but frustrating 
reStructuredText syntax (double dots, double commas, leading and trailing 
underscores, precise numbers of underlining symbols, and so on).

[2] Why does this need to go to a log? It is a critical error. I suppose the 
output of the program does summarise the log fairly nicely, and this is useful 
when pip is repeatedly failing, but then the program probably shouldn't finish 
with a message vaguely suggesting success ("Type ". activate" to activate 
venv, then "./m" for menu" or "Successfully created or updated venv").

[3] Yes, I know that the Python core developers want everyone to pretend that 
Python didn't exist before version 3, but in the real world, people still need 
to distinguish between legendary Python and Python 3. (I work in a domain 
where there are still Python 2 programs being actively used, which shows how 
much the need for constructive outreach to actual users was overlooked, as 
opposed to cheerleading amongst advocates and pundits, combined with guilt-
shaming and making needless work for the rest of the community.)

[4] Back when everyone decided that Python should have a packaging system 
"like CPAN", I guess no-one advocating that position ever had to deal with 
random Perl packages failing to build or install, leaving them in a situation 
where there is no obvious remedy. This is why we have software distributions 
like Debian where processes are in place to build and reliably deploy 
packages.