Please refer to igraph instead of python-igraph

[szhorvat]

Can you please change python-igraph to igraph in locations where pip (not conda!) may take package names? I believe these are:

https://github.com/GiulioRossetti/cdlib/blob/master/requirements.txt#L16

and maybe this:

https://github.com/GiulioRossetti/cdlib/blob/master/docs/conf.py#L55

Please see igraph/python-igraph#699 for an explanation.

Ref: https://github.com/search?q=repo%3AGiulioRossetti%2Fcdlib%20python-igraph&type=code

[GiulioRossetti]

Unfortunately this change will break the conda packaging pipeline for cdlib.

Pip and conda dependencies need to have the same signature since the conda skeleton is automatically generated from the pip package.

Is the name update planned also for the conda release?

[szhorvat]

No, it is unfortunately not. See conda-forge/python-igraph-feedstock#42 for the discussion.

[szhorvat]

To be clear, it'll probably be a while before python-igraph really stops receiving updates on PyPI, but eventually it is likely to happen. Perhaps with version 0.11.

[GiulioRossetti]

In my opinion this choice will end up damaging the developer community: basically in this way you are preventing automated skeleton building pipelines for conda packaging of those projects relying on igraph.

It is not exactly a "friendly" behaviour in Free Software/Open Source communities.

Moreover, I don't see the urgency in changing the package name apart from a stylistic perspective... This was an easily avoidable breaking change.

My suggestion: have a pip installable meta-package that maintains the old name and points to the new one until the naming across package managers will be uniformed. This way the installation stats for igraph will be more reliable and developers using it on their libraries will be spared from additional cross packaging nightmares.

[szhorvat]

CC @vtraag and @ntamas.

[szhorvat]

To give some background:

The change was not purely for stylistic reasons. On PyPI, igraph originally referred to a completely unrelated package. Even though this package got renamed to jgraph many years ago, it was causing a constant confusion for users that they were running pip install igraph and getting (an old version of) a package that didn't do what they expected. The author of this other package was kind enough to transfer the control of the igraph name, to help resolve this confusion. However, this way we ended up with two names for the same package, and it makes sense to eventually drop one of them.

Note that Conda is not a Python package manager. It is a general purpose one. It includes the C, Python and R interfaces of igraph, all of which are named "igraph" in their upstream repositories. Such multi-system package managers will inevitably need to find a way to differentiate between packages of the same name coming from different backgrounds. Thus, on Conda there is both python-igraph and r-igraph, in addition to igraph which refers to the C library.

Similar issues affect all other generic package managers and Linux distros, which have their own typical naming conventions. You can see some of the choices they made here for Python and here for R.

---

Regarding practical issues:

The primary name on PyPI will be igraph going forward. As for how long the python-igraph name will continue to be supported, this is up for discussion. As I said, it is unlikely to be dropped in the immediate future, but this is a decision for the team, hence the CCs above.

[GiulioRossetti]

I knew the background.

However, the issue still remains. And the proposed solution is by matter of fact stylistic and has repercussions.

Indeed conda is a "general" package manager but several pipy distributed packages have (name)synced conda ones. And breaking such convention breaks also automated packaging (and some ci/cd) pipelines.

Of course, maintainers are not compelled to enforce such customary naming pattern, however, as discussed, deviations might produce downstream issues (maybe not for normal users, for sure for other maintainers having projects with multiple packaging channels relying on non name aligned dependencies).

Although I understand the maintainers decision, I still think it was not particularly "friendly" w.r.t. their community.

[vtraag]

@GiulioRossetti might it not be possible to simply create a separate feedstock on conda-forge for cdlib? You could generate the skeleton, and then adapt it as required. It's not too difficult to setup, and it would allow to install cdlib without requiring the separate giuliorossetti channel you are using now. In conda it can then depend on python-igraph, while on PyPI the requirement could still point to igraph. This is absolutely no problem, and something that is completely feasible. The documentation for doing this can be found here: https://conda-forge.org/docs/maintainer/adding_pkgs.html# I'd be happy to help out if needed (although summer holidays might delay all of this).

As @szhorvat explains, there is a good reason for having different names on conda as opposed to PyPI.