-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to install Python environment? #12
Comments
Current set-up is a bit of a MVP, we can do better than this! https://github.com/geocompr/docker/blob/master/python/Dockerfile |
I'd say - it depends what are your plans with the Python flavour of the container. Since you are installing just geopandas within an ubuntu environment, it may be fine using If you plan to expand the environment then I would strongly recommend adopting |
Here's my most recent attempt: https://github.com/anitagraser/EDA-protocol-movement-data/blob/main/docker/Dockerfile Use at own risk ;-) |
@Robinlovelace awesome stuff here! Would love feedback on ways we can adjust the python install on the rocker images; we've been playing with that a bunch recently, mostly on the ML stack where support for GPU capabilities is the main concern. But it would be nice to get a more general strategy nailed down. From my experience so far, it's really quite challenging to establish flexible defaults for the python setup that cover all use cases. Like @martinfleis mentions, the flavor of python really depends on the use case -- some python libs need python < 3.7 (looking at you, all that stuff that still depends on tensorflow 1.x), some need latest python, some want to use conda versions, some need packages not on conda. The dominant models seems to be leaving this up to the users, with most installers installing python, virtualenvs (including The idea of https://github.com/rocker-org/rocker-versioned2/blob/master/scripts/install_python.sh was to provide a working python environment out of the box visible in either single-user or multi-user deploys of the rocker container, while still making it easy enough for the user to switch into different virtualenvs (i.e. not force |
Many thanks everyone for the insight, great to be learning about the Python ecosystem and seeing how different open source communities can learn from and support each other (guessing that will be a theme in @anitagraser graser's upcoming #FOSS4G talk ; ). My guess is that Docker provides some of the benefits of virtual environments (self-containerisation, known dependencies, ease of duplication) so that using My my question on In any case I think the most important thing here is whether it works. I will have a play, try installing more awesome Python packages like Momepy / OSMnx, and report back - I may ping you Martin and Anita in the future if that's OK when I inevitably hit a bottleneck, but feeling more confident after seeing general support, and very useful specific comments, from the community! |
That sounds like great advice, I will seek to add some post build tests in there to check they've linked-up correctly. |
Normally, these issues shows up on import, so |
Minor update: I just double checked if the image contains working
|
More tests... library(sf)
f = file.path(system.file("shape/nc.shp", package="sf"))
nc_sf = read_sf(f)
library(reticulate)
system("pip3 install descartes")
gp = import("geopandas")
nc_gp = gp$read_file(f)
class(nc_gp)
plot(nc_gp$AREA, nc_gp$PERIMETER)
gp = import("geopandas", convert = FALSE)
nc_gp = gp$read_file(f)
nc_gp
plt = import("matplotlib.pyplot", convert = FALSE)
nc_gp$plot()
plt$savefig("test.png") Results in this: So basically works, RStudio has got better at showing plots in recent versions I think, but we're not using recent RStudio versions. |
Note that this won't catch all issues (eg it won't catch if pyproj doesn't find PROJ or finds the wrong PROJ, and also won't necessarily show an import error of fiona, since geopandas now doesn't require it to be present).
It's certainly true that in a controlled environment as a docker container, it should be easier to use pip compared to supporting that for users' work desktop machines. And when using wheels, at that point you can get conflicts between system-installed libraries vs wheel-included libraries. So that is still a potential disadvantage of using pip (although in general on linux I think this should also be fine, and prefer the wheel-included library without giving conflicts. But this is for example a typical installation problem on Homebrew mixing GDAL/GEOS from homebrew with a pip installed fiona and shapely). |
Not through
pip
...Context: https://github.com/rocker-org/rocker-versioned2/blob/master/scripts/install_python.sh
The text was updated successfully, but these errors were encountered: