Use conda-forge label feature for LTR

[petrushy]

Solution to issue cannot be found in the documentation.

• [X] I checked the documentation.

Issue

Thanks for a good repo.

Not sure technically how to do this, but would be good to be able to only install the LTR version and not getting the latest if an update is done. I think this can be done with the conda-forge "labels", now all packages is on main.

Checking the documentation it seems like this can be specified as described in https://conda-forge.org/docs/maintainer/conda_forge_yml/#upload-on-branch for the git branch with the LTR version.

[gillins]

I don't think you can specify the label to upload with this option though... I wonder if we should have 2 separate repos instead - qgis_ltr and qgis_latest?

[SrNetoChan]

Hi!

We have talked about this in the past:

https://github.com/conda-forge/qgis-feedstock/pull/191

https://github.com/conda-forge/cfep/pull/42

The suggestion was instead to create a meta-package that would take care of building both qgis and qgis-ltr. Both I have never had the time to try it out or to see if it makes sense.

@gillins would keeping the two branches in the same repository, but renaming the output name from qgis to qgis-ltr in the LTR branch work?

[gillins]

Thanks @SrNetoChan I had forgotten about this. Yes I guess we could change the output name for the LTR branch. Not sure if this would work or we have to re add as a new recipe for this. Do we know of other repos that do this? @ocefpaf any thoughts?

[SrNetoChan]

@gillins I guess we can try locally, right? Changing the recipe and see if it spits out a valid output?

[gillins]

Yep sounds good. Is this something you can try? I won't be back at my development PC for a couple of weeks yet.

[ocefpaf]

The label idea is not bad but it would change how people install the package. One would need to do something like:

conda install "conda-forge/label/qgis_ltr::qgis"

The label is like a channel, so it should show up in any install command from environments to .condarcs if one is to manage the LTR properly.

@gillins to publish something to a different label in conda-forge one can use custom conda_build_config.yaml, like this one.

[gillins]

@ocefpaf so the post install step should add the ltr channel to the user's .condarc?

In your opinion would it be better to use this label approach than have a different package name? What do other conda forge packages do for situations like this?

[ocefpaf]

In your opinion would it be better to use this label approach than have a different package name? What do other conda forge packages do for situations like this?

Both are disruptive but I'm inclined for the LTS channel b/c it mimics the development channels that we have. Also, if we go for this solution we can move the other packages to the LTS channel. if we choose a different name we should either leave them alone or mark them as broken to avoid confusion.

[petrushy]

Many thanks for implementing this, works well!

running

conda config --env --add channels conda-forge/label/qgis_ltr

and then conda install qgis gives LTR version and keeps it during conda update --all

Thanks!

[joaoponceleao]

and then conda install qgis gives LTR version and keeps it during conda update --all

This is nice (including for conda update qgis). I never use conda update --all for the qgis environments though. I assumed that in this case it was better to let conda update qgis handle those dependencies. Anyone know what the best practice is for this? Does qgis have the required libraries pinned and we can use update --all without issues?

[ocefpaf]

@joaoponceleao, I rarely use update all. Most of my envs I either do not touch them after creation, sometimes even using conda-lock to record the exact env; Or I destroy and recreate the env. I've seen bad behavior with update all where a single poorly pinned package can cause havoc and break everything.

[SrNetoChan]

Personally, I just do update qgis and let conda decide what else it needs to update. But this is because on my env qgis is central.

[joaoponceleao]

I've seen bad behavior with update all where a single poorly pinned package can cause havoc and break everything.

Oh... I've learnt the hard way to never touch a PyTorch cuda env......