Closed Robinlovelace closed 10 months ago
The workflow is running now... https://github.com/geocompx/geocompy/actions/runs/6677253079/job/18147073177
That failed fast! No conda in that image of course...
Trying again with pip.
Results, in progress: https://github.com/geocompx/geocompy/actions/runs/6677262371/job/18147094463
Finally it's working, new pkgs being installed!
Source: https://github.com/geocompx/geocompy/actions/runs/6677334686/job/18147259476
I think this is ready to merge. Good news: our book seems to work with all versions of the latest packages :tada:
Looks okay to me. I would normally just remove pins to check latest but updating them with pur
(which I never heard of before, so thanks!) seems to work as well.
Me neither, a bit of a rabbit hole you've set me off there Martin! How would you remove pins? Possibly a simpler option. On a different but related note I cannot recall how we created the requirements.txt file, with pip freeze
like this?
Activate the environment as follows:
micromamba activate geocompy
Install kernel, this will allow you to select the environment in vscode or IPython as follows:
python -m ipykernel install --user
You can now reproduce the book (requires quarto to be installed):
micromamba run -n geocompy quarto preview
Optionally, to update the requirements.txt file based on your newly installed packages, run the following:
pip freeze > requirements.txt
Thinking of more updates to the README..
That approach with pip freeze
generates a weird output:
+++ b/requirements.txt
@@ -17,3 +17,173 @@ xarray==2023.10.1
Cartopy==0.22.0
osmnx==1.7.0
contextily==1.4.0
+affine @ file:///home/conda/feedstock_root/build_artifacts/affine_1674245120525/work
I doubt your requirements are based on pip freeze and I would advise against it. Pip freeze gives you everything in the environment, requirements typically have only a subset you directly need. My bet is that someone pinned that manually.
I doubt your requirements are based on pip freeze and I would advise against it. Pip freeze gives you everything in the environment, requirements typically have only a subset you directly need. My bet is that someone pinned that manually.
Make sense but do you see the problem: we need an automated way to go from environment.yml
to requirements.txt
or vice versa. I think we found a solution but I cannot recall it and I'm not sure if it constitutes best practice. Or we abandon one of these config files.
If you kept both without pins, you wouldn't have this issue :). You could write a simple script to do that. Requirements.txt can be copypasted to the yml file and all should work.
@martinfleis your thoughts would be appreciated, does this solve it? Thanks!