exposing the package version

[gboeing]

There seems to be something going wrong with how giddy exposes its package version (at least when installed via conda/mamba on Ubuntu). MWE:

conda create -n TEST giddy
conda activate TEST
conda list giddy  # shows version 2.3.5
pip show giddy  # shows version 0.0.0
python -c "import giddy; print(giddy.__version__)"  # shows version 0.0.0
pip install giddy --upgrade
conda list giddy  # shows version 2.3.5
pip show giddy  # shows version 2.3.5
python -c "import giddy; print(giddy.__version__)"  # shows version 2.3.5

So, when v2.3.5 is installed via conda, the package version is visible to conda, but both pip and Python itself see version "0.0.0". If I reinstall with pip, the version number is fine everywhere. Haven't seen this kind of behavior before.

[knaaptime]

ive noticed this before and i dunno wtf... will dig a bit

[jGaboardi]

This more than likely has to do with the requirements:host in recipe/meta.yaml of giddy's feedstock. Comparison with spopt's, for example.

[weikang9009]

It does look odd. However, this does not seem to apply only to giddy. esda has a similar version discrepancy between using conda list and pip show. I also observe a somewhat similar behavior when it comes to urbanaccess:

Could this be a relationship issue between conda and pip?

[jGaboardi]

Nearly certain it's the thing I mentioned above. Here's an example of both spopt & giddy from conda-forge:

(base) user@mba-13-m3-2024 ~ % conda activate py312_whats_up_with_versions 
(py312_whats_up_with_versions) user@mba-13-m3-2024 ~ % conda list spopt
# packages in environment at miniforge3/envs/py312_whats_up_with_versions:
#
# Name                    Version                   Build  Channel
spopt                     0.6.0              pyhd8ed1ab_0    conda-forge
(py312_whats_up_with_versions) user@mba-13-m3-2024 ~ % conda list giddy
# packages in environment at miniforge3/envs/py312_whats_up_with_versions:
#
# Name                    Version                   Build  Channel
giddy                     2.3.5              pyhd8ed1ab_0    conda-forge
(py312_whats_up_with_versions) user@mba-13-m3-2024 ~ % pip show spopt
Name: spopt
Version: 0.6.0
Summary: Spatial Optimization in PySAL
...
(py312_whats_up_with_versions) user@mba-13-m3-2024 ~ % pip show giddy
Name: giddy
Version: 0.0.0
Summary: PySAL-giddy for exploratory spatiotemporal data analysis
...

[jGaboardi]

The spopt version is properly recognized by both conda & pip, but with giddy only conda properly recognizes the version.

[weikang9009]

esda shares the version discrepancy issue even though it has the similar configuration in recipe/meta.yaml as spopt

[knaaptime]

i think giddy is the only one ive seen do the 0.0.0 thing? and but i notice splot also doesnt have setuptools_scm in the host requirements for its conda recipe, so i dunno

[weikang9009]

I added the two requirements in the feedstock. We will need to wait for a new release to see the effect of this change?

[jGaboardi]

Did you commit those directly without a PR? I didn't even think you could do that. I think best bet is to rerender with bumped build number.

[weikang9009]

It was an accident... I was intending to create a PR... Can you do the rerender? @jGaboardi

[jGaboardi]

@weikang9009 Let's go ahead and merge the feedstock PR, then we can try again in the morning once that version of giddy is available on conda-forge.

[jGaboardi]

Following conda-forge/giddy-feedstock#13, installing via conda we now get the proper version with both conda list * and pip show *:

(py312_whats_up_with_versions) user@mba-13-m3-2024 ~ % conda list spopt     
# packages in environment at py312_whats_up_with_versions:
#
# Name                    Version                   Build  Channel
spopt                     0.6.0              pyhd8ed1ab_0    conda-forge
(py312_whats_up_with_versions) user@mba-13-m3-2024 ~ % conda list giddy
# packages in environment at py312_whats_up_with_versions:
#
# Name                    Version                   Build  Channel
giddy                     2.3.5              pyhd8ed1ab_1    conda-forge
(py312_whats_up_with_versions) user@mba-13-m3-2024 ~ % pip show spopt
Name: spopt
Version: 0.6.0
Summary: Spatial Optimization in PySAL
...
(py312_whats_up_with_versions) 
@mba-13-m3-2024 ~ % pip show giddy
Name: giddy
Version: 2.3.5
Summary: PySAL-giddy for exploratory spatiotemporal data analysis
...

Then removing the conda install and reinstalling directly with pip:

(py312_whats_up_with_versions) user@mba-13-m3-2024 ~ % mamba remove giddy
...
(py312_whats_up_with_versions) user@mba-13-m3-2024 ~ % pip install giddy
Collecting giddy
...
(py312_whats_up_with_versions) user@mba-13-m3-2024 ~ % pip show giddy    
Name: giddy
Version: 2.3.5
Summary: PySAL-giddy for exploratory spatiotemporal data analysis
...

@gboeing Can you confirm this resolves the issue?

[gboeing]

Yep that resolved it. You guys are fast.

[jGaboardi]

@weikang9009 So do we need to re-render esda over in the feedstock?

[weikang9009]

@weikang9009 So do we need to re-render esda over in the feedstock?

It would be a good idea. Not sure whether other pysal packages have a similar issue though. We might want to list this as an item in the next meeting agenda?

[jGaboardi]

It would be a good idea.

PR in >> conda-forge/esda-feedstock#26.

We might want to list this as an item in the next meeting agenda?

Done --> https://github.com/orgs/pysal/discussions/1278#discussioncomment-9306801