search

OSGeo / homebrew-osgeo4mac

Mac homebrew tap for maintaining a stable work environment for the OSGeo.org geospatial toolset
https://git.io/fhh3X
BSD 3-Clause "New" or "Revised" License
362 stars 111 forks source link

Migrate to python@3.8 #1385

Closed jctull closed 4 years ago

jctull commented 4 years ago

Is your feature request related to a problem? Please describe.

Homebrew-core now has several formulae that are dependent on python@3.8, e.g., qt and pyqt. Because of this, if you upgrade your homebrew-core, new challenges are introduced in building additional software with mixed dependencies between the two python versions.

Describe the solution you'd like

Review the migration of homebrew-core dependencies for osteoporosis-* packages here: https://github.com/Homebrew/homebrew-core/issues/47274

Consider migration of all formula that use python to python@3.8.

alazarolop commented 4 years ago

Thank you for sharing it. I'll review it and it will be introduced with forthcoming releases. @jctull If you are interested in a specific set of formulae, you are welcome to PR the modifications.

jctull commented 4 years ago

Thank you for sharing it. I'll review it and it will be introduced with forthcoming releases. @jctull If you are interested in a specific set of formulae, you are welcome to PR the modifications.

Thanks, appreciate your efforts as always. I tried poking around last week and made a wreck of my Homebrew installation, so I probably won't have anything of use to contribute right away. I will keep an eye on things as they progress. If I find ways to get other stuff working once I know what kinds of code changes this might take, I will look for opportunities to push PRs that might speed the process along. At this point, I am in the dark on what to do. If I get some time, I will look at homebrew-core for clues.

alazarolop commented 4 years ago

Thank your for your words and for your effort too. I meant PR as a way to speed up any software you would be interested in and as long as you were able to. No worries, I'll take a look at the formulas as soon as I can. My main concern is GRASS GIS, let's see.

alazarolop commented 4 years ago

Hi @jctull , I've started on osgeo-gdal-python in order to migrate formulae to python@3.8.

In this case, I got an issue related to numpy version that I don't know how it could be fixed. Curiously, even though the main Python formula is designated withpython, it actually uses python@3.8 when installing dependencies. I reckon it's related to numpy dependencies. Would you have any thoughts?

jctull commented 4 years ago

Hi @jctull , I've started on osgeo-gdal-python in order to migrate formulae to python@3.8.

In this case, I got an issue related to numpy version that I don't know how it could be fixed. Curiously, even though the main Python formula is designated withpython, it actually uses python@3.8 when installing dependencies. I reckon it's related to numpy dependencies. Would you have any thoughts?

It doesn't appear that numpy requires 3.8 (https://github.com/numpy/numpy/releases). I suspect this is more related to the homebrew effort to migrate python packages to python@3.8 and leave python <3.8 behind, but I am not certain. I think there will continue to be challenges with this repo if python@3.8 support is not made the default. If a package that needs python can be built and work with python@3.8, that should probably be the default. Once homebrew core moves beyond 3.7 as the default python install, things will need to be updated here.

jctull commented 4 years ago

FWIW, I was able to get osgeo-gdal-python to build using python@3.8 and the stock gdal formula as a dependency. Now that you bumped osgeo-gdal to version 3.1.1, I plan to rebase my local repo. Curiously, is there still a need to duplicate gdal and proj (and postgresql/postgis)? It seems reasonable that we should reduce the number of duplicate packages assuming the homebrew-core packages are being regularly updated. I know this is a bit off-topic, but it could reduce complexities and may also streamline the transition to python@3.8.

alazarolop commented 4 years ago

@jctull Could you create a PR to the "bottles" branch so we can discuss about the modifications.

No worries, it's an important topic related to the migration and now that core serves the latest GDAL version. I think two main reasons to maintain PROJ / GDAL formulae could be control and functionality. Core tries to make available the latest versions and this can create issues with dependent software that isn't still updated, e.g. sf and rgdal R package or GRASS, specially in the transition from PROJ < 5 and GDAL < 3. Besides, GDAL from tap serves a wider range of drivers than core version. It happens the same with PostgreSQL, it also includes the python extension (the last time I checked it's not available in core) and the tap let you choose a PostGIS and PostgreSQL combination.

I wonder if the extra funcionality makes worthy a tap though or another way could be recommended instead. For example, extra drivers can be found in GDAL docker image.

stale[bot] commented 4 years ago

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want to keep the issue open, please comment or update the info here. Thank you for your contributions.

stale[bot] commented 4 years ago

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want to keep the issue open, please comment or update the info here. Thank you for your contributions.

stale[bot] commented 4 years ago

This issue or pull request has been automatically closed because it has not had recent activity. Thank you for your contributions.