[FEATURE] make pygmo available for python 3.9

[giovannifi]

I am trying to install the module with the command:

pip install pygmo

in a python 3.9 environment but I get the following error message:

ERROR: Could not find a version that satisfies the requirement pygmo (from versions: none)
ERROR: No matching distribution found for pygmo

Is there any possibility to make pymgo available for python 3.9?

thanks in advance Giovanni

[FraserParlane]

Agreed!

[bluescarni]

I am working on a new pagmo release, once that is out I'll add the pygmo2 pip builds for python 3.9 as well.

Note that pygmo2 builds for python 3.9 are available in conda.

[bluescarni]

@darioizzo is working on updating the pip builds, but we don't have an ETA yet.

[spraguecaleb]

I am facing this issue also. Using Python 3.9.7 on windows. I tried to clone and build locally with cmake, but I get an this "Error: could no load cache".

[pradyparanjpe]

python3.10 too?

[jetuk]

Is there any update on getting the latest wheels on PyPI?

[darioizzo]

We are slowly abandoning support for pypi wheels ... any reason not to use conda?

On Mon, 21 Feb 2022, 13:51 James Tomlinson, @.***> wrote:

Is there any update on getting the latest wheels on PyPI?

— Reply to this email directly, view it on GitHub https://github.com/esa/pygmo2/issues/76#issuecomment-1046844359, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZMI32RN3ABXHLAORUSO4LU4IYLNANCNFSM5BHUSWUQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[jetuk]

It's the method and format for Python packages endorsed by the PyPA. Conda is also not free for larger commercial organisations.

If your reason for dropping PyPI wheels is because of the maintenance burden (which I can understand), then you (or another contributor) might consider cibuildwheel. It helped my project a lot getting standard wheels built.

Finally, it might be useful to have a statement in the README notifying users that the PyPI packages will no longer be updated if that is the policy going forward.

[matteoettam09]

+1

regular pip user, reading the documentation I tried without success to install with pip. Maybe the pip section here should be removed from the docs?

[bluescarni]

It's the method and format for Python packages endorsed by the PyPA.

That does not really apply to pygmo, as it's primarily a C++ project with C++ dependencies. pip is not able to understand dependencies in other languages (and it could be argued that it barely understands dependencies among python packages, but that's another discussion).

The auditwheel hack of bundling shared objects together with the compiled Python module kind of works as long as you look at a single package in isolation, but fails terribly once multiple packages start bringing in their own competing and incompatible versions of the same shared objects.

Conda is also not free for larger commercial organisations.

My understanding is that packages on conda-forge (where pagmo/pygmo are distributed) are free to use for anyone. Could you elaborate a bit on this?

If your reason for dropping PyPI wheels is because of the maintenance burden (which I can understand), then you (or another contributor) might consider cibuildwheel. It helped my project a lot getting standard wheels built.

I am not opposed to having wheels, in fact I'd be really happy if someone stepped up and fixed/maintained them. I just don't want to do it myself, as the maintenance of the conda packages is already time consuming enough.

I skimmed a bit over the documentation of cibuildwheel and I saw no mention of integration with CMake. The difficult part of building wheels for pygmo is doing it in a way that minimises duplication with the existing (CMake-based) build system. Properly maintaining one build system is time consuming enough, having two of them to take care of would be insane :)

I have been using scikit-build with some success on the job:

https://scikit-build.readthedocs.io/en/latest/skbuild.html

It takes care of the build system duplication issue, but on the other hand it cannot solve the fundamental issue of dealing with non-Python dependencies in a safe manner (only conda or another multi-language package manager can).

Finally, it might be useful to have a statement in the README notifying users that the PyPI packages will no longer be updated if that is the policy going forward.

I'll make sure to add some text for the next version.

[darioizzo]

117 provides the new wheel. Will be available at the next release.