search

macports / upt-macports

The Universal Packaging Tool (upt) backend for MacPorts
https://framagit.org/upt/upt
BSD 3-Clause "New" or "Revised" License
8 stars 12 forks source link

populate python.versions only with supported Python versions #6

Closed reneeotten closed 2 years ago

reneeotten commented 5 years ago

The json file from PyPI contains a requires_python field that upstream can use to specify support Python versions. If this is present (not sure whether upt or upt-pypi currently parses it), we should compare our "default" versions with this specification and only populate python.versions with the ones that are supported.

Steap commented 5 years ago

Hey!

This is a great idea, but I feel like this information is often quite unreliable:

1) It is not mandatory, so lots of packages will be missing it 2) Setting it to a "wrong" value will not break anything on the developer's side: if they write "we need 3.6" and never update the field, we might wrongfully think that 3.7 is not supported.

Here are the occurrences of "python.versions" I could find in macports, sorted by the amount of uses:

443 python.versions 27 34 35 36 37
378 python.versions 27
173 python.versions 27 34 35 36
102 python.versions 27 35 36 37
 94 python.versions 27 36 37
 41 python.versions 27 37
 34 python.versions 27 35 36
 19 python.versions 37
 14 python.versions 36 37
 13 python.versions 35 36 37
 12 python.versions 34 35 36 37
 11 python.versions 26 27 33 34 35 36 37
 10 python.versions 27 36
  8 python.versions 36
  6 python.versions 27 34
  5 python.versions 26 27
  4 python.versions 27 33 34 35 36 37
  3 python.versions 34 35 36
  3 python.versions 26
  2 python.versions 35 36
  2 python.versions 26 27 32 33 34 35 36 37
  1 python.versions 27 33 34 35 36
  1 python.versions 27 
  1 python.versions 26 27 34 35 36 37
  1 python.versions 26 27 33 34 35 36

Python 2 will die on January the first. Python 3.4 reached end of life earlier this year (see https://devguide.python.org/#status-of-python-branches) so Python 3.2 and 3.3 are probably EOL as well. Which leaves us with 3.5, 3.6 and 3.7. If we specify "35 36 37" by default and the package is only compatible with 3.6 and 3.7, is there a CI that will catch the issue?

reneeotten commented 5 years ago

I see your point, but still think we should set the version "to the best of our knowledge" (it's anyway something the maintainer should double-check). The CI should catch it when we specify incorrect Python versions; but again, only if this is specified correctly in the setup.py file.

  1. if it's the variable not present, we will use whatever we decide to be the default, right now python.versions 37, which should probably for now become anyway python.versions 27 36 37 for new ports
  2. if it's set incorrectly by upstream, there is not much we (or upt) can do about it; if it's set, we should assume it is done so properly

Regarding EOL versions.... this is always a difficult topic. Generally, removal of EOL Python versions should done by simultaneously for all packages in order not to break things - in practice this always takes a while to do...

Korusuke commented 5 years ago

So for doing this, we would have to update upt-pypi as that is what parses the JSON from PyPi and then once that's updated then we can add the feature here.

So should I push PR to the upt-pypi repo?

reneeotten commented 5 years ago

I would consider this "nice-to-have-but-not-too-high-on-the-priority-list", so I am fine with revisiting this at a later stage.

Steap commented 5 years ago

Yes, for now having a reasonable default hardcoded in the template might be OK.