Use in Plone 5.2?

[wesleybl]

Is it possible to use this package in a Plone 5.2 and 6.0 compatible product?

[gforcada]

Hi! 👋🏾

Probably as it is right now, not really, as we use a constraints file to define which packages get installed 😕

Since #139 we allow to provide a custom constraints file, which at least it would allow you to choose if you want to use a 5.2 based constraints file, or a 6.0 one.

Oh wait! 💡

Almost all configured files have a extra_lines configuration option.

If you duplicate the tox.ini test and coverage sections to use a different constraints file and add that to the extra_lines you will be able to run as much targets as you want 👍🏾

It might be a bit tedious, but at least is full flexible on how much you can do 🍀

Notice though, that between 5.2 and 6.0 there is quite a jump in terms of code changes etc, so as a way to test them in both in parallel, might work, but your code can easily get tricker.

If I was to be asked, I would first configure everything only focusing in 5.2. Once that's stable and running you can move the configuration to 6.0 and keep a stable/frozen branch for 5.2.

If the add-ons are meant to keep 5.2 and 6.0 compatibility for a long term, then we need to extend tox.ini quite a bit more to allow more hooks.

It's not impossible at all, it only means that it is not ready for this use case 😅

Actually, for 6.1 and even more for 7.0, we will have to deal with this multiple plone versions (and here we are ignoring the python matrix as well 😵‍💫 ).

So to phrase the other way around: thanks for stepping up and paving the way to make plone/meta able to be used in multiple plone versions 😉

Ping me for any problems/shortcomings you keep seeing on the way 😄

[wesleybl]

Looks like it's a little far from working, right 😢 ?

As you said, this will be needed for Plone 6.1. It is necessary to consider the Plone version in the matrix and associate it with the Python version. I see that today jobs only run in Python 3.11. And I saw this here:

meta/.github/workflows/test.yml

Line 15 in 23d5b8e

python-version: ${{ fromJSON(vars.TEST_PYTHON_VERSIONS) }}

Where does vars.TEST_PYTHON_VERSIONS come from?

[jensens]

IMO we should keep all 5.2 as is. It is in maintenance mode.

[gforcada]

@jensens yes for Plone core packages, but I get that @wesleybl is mostly thinking about using it on third party/collective packages.

@wesleybl that string is coming from GitHub itself, so you can define the python version in a organization or per-repository fashion: https://docs.github.com/en/actions/learn-github-actions/variables

This was done when the idea was to use plone/meta only for Plone core packages.

If we extend this to external packages we might either ditch that, or even create another default folder.

The idea of this default folder is that you can have different project layouts (see the original zopefoundation/meta with different settings and configurations. On zopefoundation they have 4 different folders.

Although I would very much try to keep a single folder as much as possible, it might very well be that at some point we want to have two, three or more different project layouts.

[wesleybl]

@jensens yes for Plone core packages, but I get that @wesleybl is mostly thinking about using it on third party/collective packages.

Yes. i was asked for an addon.

Well, the idea of a github variable for an addon may not be very good, because not everyone has access to the configuration and each project can be different.

Anyway, this was just a question, not a feature request.

Many thanks to everyone for the clarifications!

[gforcada]

Actually, I want to get a 5.2/6.0 support for https://github.com/collective/collective.contentalerts/ 😄

So it might come sooner than later 🎉

Please bring you needs and ideas for it! 🍀