Transfer project to PyPA?

[untitaker]

I think it's a good fit for that org, and would help with contributor activity.

[RonnyPfannschmidt]

would they take it?

[untitaker]

No idea. @sigmavirus24, do you know if PyPA is willing to take over third-party projects?

We should discuss this with @mitsuhiko first of course.

[sigmavirus24]

That's a good question. I don't think we'll discuss it before @mitsuhiko weighs in. Also, I'm not certain that moving it to PyPA would significantly help garner new contributors.

[westurner]

• User irc:#pypa | Dev irc:#pypa-dev
• https://github.com/pypa
• https://github.com/pypa/pypa.io
  • https://www.pypa.io/en/latest/
    • https://pypaio.readthedocs.org/en/latest/
• https://github.com/pypa/python-packaging-user-guide
  • https://packaging.python.org/en/latest/projects.html (Project Summaries)
    • https://github.com/pypa/python-packaging-user-guide/edit/master/source/projects.rst
    • https://python-packaging-user-guide.readthedocs.org/en/latest/

... It would be great to add peep as well. (... conda-archive/conda-recipes#308)

[sigmavirus24]

@westurner once again, I'm at a loss for what the point is in your comment. You've linked a whole bunch of docs and projects without giving any other substance.

[untitaker]

I don't know either what you mean @westurner

[westurner]

Are there any other links that would be helpful for possibly moving this project to PyPA (as linked) (if that's necessary)?

• It may be helpful to add links to pipsi in the python-packaging-user-guide

[sigmavirus24]

@westurner this discussion isn't a matter of link aggregation

[westurner]

If you have more resources for moving this forward, do let me know.

Some people to include in this discussion might include #pypa.

Does pipsi fit with the core mission of PyPA? There are the links to the organization.

In order to "Transfer project to PyPA", there would need to be some docs,
particularly in the python-packaging-user-guide (linking to pipsi, describing what pipsi does).

[untitaker]

@westurner We will reach out to them if @mitsuhiko agrees to it (the author of pipsi), but so far we've been unable to reach him.

[westurner]

@untitaker @mitsuhiko

• Pipsi is a very useful tool
• Pipsi-installed console_scripts are faster (because their sys.path is determined by a unique* virtualenv)
• Here's mitsuhiko/pipsi v0.8 as a conda-recipe: ENH: pipsi 0.8: conda skeleton pypi --recursive pipsi --version=0.8 conda-archive/conda-recipes#311
• pypa/pipsi or mitsuhiko/pipsi

@dstufft Would it be possible/feasible/advisable to add pipsi functionality to pip?

[untitaker]

Pipsi is a very useful tool

We know that, there's nothing speaking against pipsi from a technical perspective. This is mostly politics.

Would it be possible/feasible/advisable to add pipsi functionality to pip?

That's an interesting idea, but I think it's slightly out of scope, and pipsi is yet too young to show whether this approach is one worth pursuing.

[westurner]

Would it be possible/feasible/advisable to add pipsi functionality to pip?

• pip doesn't require click at this time
• pip pipsi [--opts] / pip console_scripts [--opts] [...]

Comparable pip functionality:

• There used to be an -E switch for specifying which virtualenv pip would install in
• Basically like flagged/tagged virtualenvs that install with pip install --user (into ~/.local/bin)
• virtualenv/virtualenvwrapper accept a list of packages to install at build time (https://github.com/mitsuhiko/pipsi/blob/master/pipsi.py#L233)

[untitaker]

Right, I think this is going slightly off-topic.

Including pipsi into pip is really out of the question at this point, and I don't think that any semi-official project related to packaging has to be molded into pip. E.g. twine seems to actually benefit from not having to maintain backwards compatibility as much as setuptools does.

[RonnyPfannschmidt]

fwiw, i already have various ideas for pipsi successors, just not the time to start the POC

[westurner]

Right, I think this is going slightly off-topic.

Including pipsi into pip is really out of the question at this point, and I don't think that any semi-official project related to packaging has to be molded into pip. E.g. twine seems to actually benefit from not having to maintain backwards compatibility as much as setuptools does.

Not at all; for purposes of documenting distinctive features and reducing community duplication, it's helpful for me to compare and contrast. (e.g. for projects.rst linked above)

[untitaker]

@westurner This issue is here to discuss the topic given in its title. It's not your personal wiki.

[westurner]

Okay, so moving this project to pypa would require:

• talk to #pypa
• create pypa/pipsi
• add pipsi to projects.rst

Thanks!

[blueyed]

I also wonder how "pyenv" fits in here.
It could provide some kind of default venvs in its shims' path, that would be looked up always.

[RonnyPfannschmidt]

@westurner the first step is stable maintainer-ship, unless that exists, its absolutely pointless to try move the project to pypa - since all it would do is burden pypa with a improperly maintained project

[ncoghlan]

Just noting that we actually have an open issue in pypa/packaging.python.org#406 discussing providing explicit recommendations for command installers (and pipsi is one of the main options on that list).

[theacodes]

Just fyi- it's not at all requirement to be a PyPA project to be documented on packaging.python.org.

Becoming a PyPA project mostly just involves adopting our code of conduct. There's some finer details to that, but that's the biggest part.

[theacodes]

(& yes, we generally will take projects and arrange for backup maintainers if necessary, like we did with twine)