-
Notifications
You must be signed in to change notification settings - Fork 799
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
Introduce PROJ_DATA environment variable to deprecate PROJ_LIB #3253
Conversation
Given its looong existence and to avoid disruption in existing workflows, PROJ_LIB will still work for the time being, and should probably be kept functional at least for the PROJ 10 series. A runtime debug message is logged (PROJ_DEBUG>=2) if using PROJ_LIB to point to the recommended PROJ_DATA. The PROJ_LIB_ENV_VAR_TRIED_LAST CMake option is renamed consistently to PROJ_DATA_ENV_VAR_TRIED_LAST and a CMake warning is emitted when the old name is used (in which case the value of PROJ_LIB_ENV_VAR_TRIED_LAST is used for PROJ_DATA_ENV_VAR_TRIED_LAST) The rational for this change is: - PROJ_LIB is a misleading name. Some users believe it is related to the loading of the PROJ executable library. - to align nicely with GDAL_DATA since they are about the same thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm good with this change and I think it is sufficiently friendly to those relying on the variable being PROJ_LIB
. As far as I read the code only CMake makes noise about this. Would it be too annoying to put out a deprecation notice everytime one of the command line apps is run? Similar to what Python does on DeprecationWarnings. It's annoying but effective.
Once merged, I'd like to see a new issue on removing support for PROJ_LIB
. Put it in the 10.0.0 milestone (I think it's far enough in the future).
Great change, as PROJ_LIB is a misleading name for a data directory. Any reason why reference to PROJ_LIB are not updated in README.md? Or should these be deferred to later (as to not confuse users that land on the first GH page and think they are seeing information for the current release). |
I had missed that reference, but your justification is a good one :-) |
PROJ 9.1 recognizes the PROJ_DATA environment variable, as a replacement for PROJ_LIB (both are still recognized by PROJ >= 9.1. PROJ_LIB will be retired in PROJ 10, whose release is unplanned for now) Cf OSGeo/PROJ#3253
PROJ 9.1 recognizes the PROJ_DATA environment variable, as a replacement for PROJ_LIB (both are still recognized by PROJ >= 9.1. PROJ_LIB will be retired in PROJ 10, whose release is unplanned for now) Cf OSGeo/PROJ#3253
PROJ 9.1 recognizes the PROJ_DATA environment variable, as a replacement for PROJ_LIB (both are still recognized by PROJ >= 9.1. PROJ_LIB will be retired in PROJ 10, whose release is unplanned for now) Cf OSGeo/PROJ#3253
PROJ 9.1 recognizes the PROJ_DATA environment variable, as a replacement for PROJ_LIB (both are still recognized by PROJ >= 9.1. PROJ_LIB will be retired in PROJ 10, whose release is unplanned for now) Cf OSGeo/PROJ#3253
PROJ 9.1 recognizes the PROJ_DATA environment variable, as a replacement for PROJ_LIB (both are still recognized by PROJ >= 9.1. PROJ_LIB will be retired in PROJ 10, whose release is unplanned for now) Cf OSGeo/PROJ#3253 Co-authored-by: Even Rouault <even.rouault@spatialys.com>
Given its looong existence and to avoid disruption in existing workflows,
PROJ_LIB will still work for the time being, and should probably be kept
functional at least for the PROJ 10 series.
A runtime debug message is logged (PROJ_DEBUG>=2) if using PROJ_LIB to
point to the recommended PROJ_DATA.
The PROJ_LIB_ENV_VAR_TRIED_LAST CMake option is renamed consistently to
PROJ_DATA_ENV_VAR_TRIED_LAST and a CMake warning is emitted when the old
name is used (in which case the value of PROJ_LIB_ENV_VAR_TRIED_LAST is
used for PROJ_DATA_ENV_VAR_TRIED_LAST)
The rational for this change is:
loading of the PROJ executable library.