conda-forge / conda-forge/conda-forge.github.io

Whether to remove Python versioned entrypoint scripts

Aperta
#205 1 commento 0 reazioni 0 assegnatari Vedi su GitHub
Lingua principale
JavaScript
Stelle
170
Fork
320
Merge medio
2g 10h
PR unite (30g)
5

Descrizione

It has come up recently in a few place about whether Python versioned entrypoint scripts should be kept or not.

While it is true that we often don't need these scripts, it is not clear to me that the effort to remove them is justified. Please see PR ( https://github.com/conda-forge/staged-recipes/pull/1161 ) for an example of such a case, related discussion, and the result of this removal. When asking upstream if we could have an option to remove them ( https://github.com/nedbat/coveragepy/issues/13 ) during install, the response was basically they don't seem to be causing a problem. To be honest, I have to agree.

To give the current lay of the land, we don't actually have any consistency about this within Python packages. For non-Python packages, we don't tend to remove versioned executables. There are some cases where we actually do this cleanup like `pip`. However, there are other cases like `setuptools` (`easy_install`) where we do not. Not to mention, other cases like the `python` binary. Other more distant examples from the Python use case include things like `ncurses` (`ncurses5-config` and `ncurses5.4-config`). Note that there is no `ncurses-config` provided (though maybe there should be 😕).

Though I would really like to avoid discussing and going through this work in a bunch of places without having the discussion at the org level. It may be that we are not actually in any kind of agreement about doing it in the first place. Also, I would like to hear some demonstration of the problem this actually solves that merits the work required. Thus far this seems to be a matter of preference (`conda` environments have only one Python). However, that rationale fails to recognize use cases where multiple Pythons may in fact be involved (system vs. `conda` or multiple conda environments/future subenvironments). It also fails to recognize we are changing the standard install from how the author intended it. Finally it fails to recognize the burden that we are then placing on recipe maintainers for unclear gain. Though there may be info from other perspectives that I'm simply missing and it would be great to hear them. I'm hoping that at the end of this discussion we can agree on one way to do this and stick with it.

Guida per i contributori

Apri la guida per i contributori

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.