Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Cc: python <python@g.o>
Subject: [gentoo-dev] [RFC] The right approach to python-r2 (-r3?)
Date: Wed, 04 Mar 2020 12:07:52
Message-Id: 4d8d3412ceb873a63893a488ed52fa329e4a251c.camel@gentoo.org
Hi, everyone.

After sending the recent proposal for python-r2 eclass suite, I've
realized that I have ended up somewhere in the middle of two possible
goals.  Therefore, I'd like to take a step back and ask what kind of
python-r2 suite would be preferable.

I see two basic options: either we go for removing deprecated API while
keeping the changes to the bare minimum possible without runtime
testing, or we go for changing some more and require runtime testing
when porting.  Let me expand on both concepts.


Approach A: minimal API changes
===============================
In this approach, I make only clearly cut API changes.  It will be
possible to migrate most of the ebuilds via a bunch of seds in a script,
and to detect cases needing manual update via some more greps.  This
will make the migration quick and mostly painless.

As an implication of that, I would keep support for all old EAPIs
and not make any of the runtime warnings more fatal than they are right
now (particularly DISTUTILS_USE_SETUPTOOLS remains a warning).

The migration plan would be roughly to:

1. Prepare a script converting ebuilds to new eclasses.

2. Run a test conversion and pass it over to Toralf for random testing.

3. Push the conversion.

4. Deprecate the old eclasses.

5. Convert remaining ebuilds manually (those that script can't convert).

6. Last rite the old eclasses.


Approach B: maximum cleanup
===========================
This approach involves making all current warnings fatal, and removing
support for old EAPIs.  While script would still help updating ebuilds,
it will be necessary to test every migrated ebuild.

The migration plan would be roughly to:

1. Prepare the script.

2. Convert some ebuilds on bumps.

3. Deprecate the old eclasses.

4. Wait forever for ::gentoo to be converted.

5. Last rite the old eclasses.

6. Wait again.

7. Remove the eclasses and hear people complaining that 6.5 years were
too short to migrate over.


Approach C: hybrid approach
===========================
Alternatively, I could combine both approaches: commit python-r2 suite
that follows approach A, and python-r3 suite that follows B.  For
practical reasons, the -r3 eclasses would probably boil down to:

  _PYTHON_R3_API=1
  inherit python...-r2

as they would merely enforce stricter warning rules.

The migration plan:

1. Prepare the script.

2. Run a test conversion to -r2, ask Toralf, push it.

3. In parallel, start manually switching to -r3 on bumps.

4. Deprecate -r1 and -r2.

5. Convert remaining ebuilds from -r1 to -r3.

6. Last rite -r1.

7. Wait forever.

8. Last rite -r2.


Summary
=======
So to summarize, of the three proposed approaches:

1. A & C provide for fast cleanup of old API with mostly-automated
conversion.

2. B & C provide for gradual cleanup of warnings and old EAPIs, i.e.
stuff requiring runtime testing.

3. A & C makes it possible to get rid of -r1 shortly and reduce
maintenance effort.


What do you think?


-- 
Best regards,
Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] [RFC] The right approach to python-r2 (-r3?) "Haelwenn (lanodan) Monnier" <contact@×××××××××.me>