Repository navigation
version: Version bump to 8.1, use no version, cosmetics - #2084
Conversation
Completes 029cd8e - grass80 -> grass81 updates in HTML pages, Dockerfiles and other files across the code tree
wenzeslaus
left a comment
wenzeslaus
left a comment
There was a problem hiding this comment.
All look good to me including the changes to something else than 8.1. I especially appreciate the fix of grass.itc.it :-) and other outdated links.
|
|
||
| # Create generic GRASS GIS lib name regardless of version number | ||
| RUN ln -sf /usr/local/grass80 /usr/local/grass | ||
| RUN ln -sf /usr/local/grass81 /usr/local/grass |
There was a problem hiding this comment.
Candidate for a bigger change? Something like ln -sf /usr/local/grass* would work too, no? There is only one GRASS in that Docker image. (Same for all Dockerfiles.)
Or ever bigger change, why it is installed to grassXY in the first place? I have /usr/local/share/zsh/ and /usr/local/lib/R there (although I have /usr/local/lib/python2.7/ there too). Obviously, at least this piece is outside of scope of this PR and thus just a side note.
There was a problem hiding this comment.
Candidate for a bigger change? Something like
ln -sf /usr/local/grass*would work too, no? There is only one GRASS in that Docker image. (Same for all Dockerfiles.)
We had that already in the past and it failed (don't recall well why, perhaps it let to a recursive effect somehow). See f1a46d6 for the revert in last summer.
Or ever bigger change, why it is installed to grassXY in the first place? I have
/usr/local/share/zsh/and/usr/local/lib/Rthere (although I have/usr/local/lib/python2.7/there too). Obviously, at least this piece is outside of scope of this PR and thus just a side note.
The point is: how to then have distinct GRASS versions installed? But perhaps for another PR...
There was a problem hiding this comment.
Candidate for a bigger change? Something like
ln -sf /usr/local/grass*would work too, no? There is only one GRASS in that Docker image. (Same for all Dockerfiles.)We had that already in the past and it failed (don't recall well why, perhaps it let to a recursive effect somehow). See f1a46d6 for the revert in last summer.
Or ever bigger change, why it is installed to grassXY in the first place? I have
/usr/local/share/zsh/and/usr/local/lib/Rthere (although I have/usr/local/lib/python2.7/there too). Obviously, at least this piece is outside of scope of this PR and thus just a side note.The point is: how to then have distinct GRASS versions installed? But perhaps for another PR...
Agree this is a question for another PR, but we have already stripped the version from grass executable. For multiple version-installations alternative --prefix and --exec-prefix may be set.
There was a problem hiding this comment.
...Something like
ln -sf /usr/local/grass*would work too, no?......it failed (don't recall well why, perhaps it let to a recursive effect somehow). See f1a46d6...
Hm, I don't see a PR or an error related to that, so hard to say. It worked in other places at least for the executable. I have seen (less general) grass?? elsewhere, so perhaps you or someone else successfully addressed the issue, whatever it was, this way.
...why it is installed to grassXY in the first place? I have
/usr/local/share/zsh/and/usr/local/lib/Rthere...The point is: how to then have distinct GRASS versions installed?
Definitively another PR. But what is the use case when you need to have two GRASS versions installed side by side like this? Certainly, it is not these Dockerfiles. I would think that developers don't install the software with sudo to a system location like this either, or? PATH/environment modification and aliases can be used to have custom setups of multiple versions of the same software. Environment modification is exactly what tools like Python virtual environments are using.
| <h3>Usage in Python scripts</h3> | ||
|
|
||
| <a href="https://grass.osgeo.org/grass80/manuals/libpython/">GRASS | ||
| <a href="https://grass.osgeo.org/grass81/manuals/libpython/">GRASS |
There was a problem hiding this comment.
We have grass-stable, so why not grass-development, grass-preview (following naming on the website), or grass-main (following branch name)? (It makes sense to me to merge this PR without/before implementing this suggestion.)
There was a problem hiding this comment.
Indeed we also have
https://grass.osgeo.org/grass-devel/manuals/
At time it doesn't point to anything useful but once this PR is merged we will have grass81 on the server shortly.
So I'll update this PR accordingly.
wenzeslaus
changed the title
* GRASS GIS 8 dev: version bump to grass81: Completes 029cd8e * grass80 -> grass81 updates in HTML pages, Dockerfiles and other files across the code tree * HTML: change https://grass.osgeo.org/grass81/ to https://grass.osgeo.org/grass-devel/
* GRASS GIS 8 dev: version bump to grass81: Completes 029cd8e * grass80 -> grass81 updates in HTML pages, Dockerfiles and other files across the code tree * HTML: change https://grass.osgeo.org/grass81/ to https://grass.osgeo.org/grass-devel/
* GRASS GIS 8 dev: version bump to grass81: Completes 029cd8e * grass80 -> grass81 updates in HTML pages, Dockerfiles and other files across the code tree * HTML: change https://grass.osgeo.org/grass81/ to https://grass.osgeo.org/grass-devel/
Fixes #2080 and completes 029cd8e. In addition to #2083.
(note: the milestone isn't exactly 8.2.0 but it needs to be redone in the upcoming
release_branch_8_2branch)