Not support EOLed 3.6 or older

[PallHaraldsson]

I'm unclear which version you download by default, I suggest latest 3.10.x. Recent versions of all versions down to 3.7, and likely way far back have security issue, see: JuliaPy/PyCall.jl#986

Not stating support is mostly a service to your users, and yourself so they and you indirectly may not get into trouble. You could amend to has been tested down to 3.5, worked at some point, not recommended.

[skip ci]

[PallHaraldsson]

I'm not sure it matters to you, but Python has been adding UTF-8 support, including a PEP for 3.7 and later (so another argument to not support older?), but it's a command-line option, so may not matter for calling Python, while it might for the other direction? Do you need to change some defaults then, and tag a major upgrade?

JuliaPy/PyCall.jl#986

[cjdoris]

The Python version downloaded depends on what constraints you've put into CondaPkg. The only constraint PythonCall makes is it has to be 3.5 or higher. So right now you'll get 3.10 by default.

If the security issue is bad, it should presumably get fixed and the bad versions yanked from Conda. So outside the scope of this package.

The encoding thing shouldn't affect this package - I don't think I assume any encoding anywhere without it being explicitly specified. (File an issue if I'm wrong though.)

[PallHaraldsson]

You could change the docs only, your call, even if 3.5 will still work, just to signal it shouldn't be used. I didn't look into constraints, actually blocking use on 3.5 (and 3.6). Again your call, to block or warn somehow.

If the security issue is bad, it should presumably get fixed and the bad versions yanked from Conda.

Yes, bad, multiple security issues, the older Python's are "cursed releases":
https://pythoninsider.blogspot.com/2022/03/python-3103-3911-3813-and-3713-are-now.html

Since 3.5 and 3.6 will not be fixed upstream, I doubt they will be fixed in Conda or elsewhere. I don't know if they have a policy of yanking releases or how quickly.

At least they haven't already and even support 2.7 (so I assume they don't yank, as 2.7 has had security issues for months):

https://docs.conda.io/projects/conda/en/latest/user-guide/tasks/manage-python.html?highlight=Python%202.7#managing-python

Anaconda supports Python 2.7, 3.6, 3.7, and 3.8. The default is Python 2.7 or 3.8, depending on which installer you used:

For the installers "Anaconda" and "Miniconda," the default is 2.7.

For the installers "Anaconda3" or "Miniconda3," the default is 3.8.

[cjdoris]

I suppose that, given PythonCall might be being used without the user even knowing (e.g. they are using a package which internally uses PythonCall) then it may be a good idea to restrict the versions in CondaPkg.toml to "safe" versions. Some options:

• Leave things as-is, i.e. support the lowest version that PythonCall can actually be used with (currently >=3.5,<4).
• Support the lowest version still receiving security fixes (currently >=3.7,<4).
• Support only the latest most-secure versions (currently something like >=3.7.13,<3.8 | >=3.8.13,<3.9 | >=3.9.11,<3.10 | >=3.10.3,<4).

Any thoughts?

[PallHaraldsson]

I would think the middle option, but download by default the latest minor version, i.e. last option. But Conda does that automatically, so would be implicit in middle option?

With 3.5 quite old I'm not sure any software only works there (but plausible...), or software needed for Julia, and since you default to the latest major one, this is mostly academic? If you're ruling any (important) software out with such a change (PR), it could be relaxed later if turns out to be a problem (at least this doc PR only would be harmless).

I suppose you could a) go for the middle option, and I'm not sure if it needs to be a major (semver) upgrade to your package, but at least a minor version upgrade.

I don't want to increase your maintenance burden, but you could b) go with the last option, if you've already done a) as a minor version upgrade to your package, i.e. assuming you've restricted to 3.7+ first. To simplify you could combine step a) and b) in a major version upgrade.

I suppose Python, like Julia and PostgreSQL, have a recommendation for the latest minor version. In exceptional cases you want to be able to use older minor or major (in my case mostly to benchmark stuff across Julia versions, I otherwise mostly use Julia master...). People ave then always the option of using an older version of your package, or using the system or provided Python with the env var for a path to such. I don't think you need any other non-default option. It seems like a lot to expect of you to do the last option and upgrade your package for each time there's a released minor Python, but as a one time thing to up-the-floor, seems valuable; since you would be restricting major versions anyway (then consider doing so every time a mojor version of Python is dropped).