PEP 541 Request: `install`

[FFY00]

Project to be claimed

PROJECT_NAME: https://pypi.org/project/install

Your PyPI username

USER_NAME: https://pypi.org/user/FFY00

Reasons for the request

Name squatting.

Maintenance or replacement?

Replacement.
Upstream: https://github.com/FFY00/python-install

Contact and additional research

I contacted the owner, he confirmed he was name squatting. His main argument was that he is trying to prevent the abuse of the namespace to distribute malware, however I have a valid use for it.

The full details:

I lurked google and the owner's github page for the project but I couldn't find it, I contacted him on the 28th of May:

Hey Eugene,

Sorry to contact you this way. As you may know, Python packaging is
changing, as defined in PEP517[1]. Because of this Linux distributions
will have to adapt the build and install workflows. The use of
setup.py install is also being removed, forcing us to change the
workflow to build and install wheels. It looks like the PEP517 and
setuptools compatible workflow will be using build[2], to build wheels,
and install[3], to install the wheels, at least these seem like the
most promising tools at the moment.
I am actually the author of install[3] and I would like to release it
in PyPI under the 'install' namespace, but as you might remember, it is
already taken by your install[4] project. I search for the project page
for a bit but couldn't find anything. Is the project still active?
I wanted ask you if you would consider giving up that namespace?

To release it you can simply remove the package or or transfer it to me
(FFY00).

If you have any questions, please let me know.
Any help with this would be greatly appreciated :)

[1] https://www.python.org/dev/peps/pep-0517/
[2] https://github.com/FFY00/python-build
[3] https://github.com/FFY00/python-install

Cheers,
Filipe Laíns

He reached out on the 10th of June:

Hello Filipe,

Thank you for reaching out to me. PEP-517 sounds exciting, and the work you're doing on it is great. However, at this time I do not wish to transfer the install project. Due to typographical errors that occur, the usage of the pip package, 'install', is dangerous. I believe package installation should be delegated to pip solely.

Best,
Eugene

I replied the same day:

Hi Eugene,

I have written some thoughts about pip vs distribution package
management here[1], please have a look. The sum of it is that just
doesn't work well when binaries start appearing.

If you are just talking about using pip to install the wheels, instead
of this new install package, the sort answer is that it is not
compatible with several workflows, the main on being Linux
distributions.
Our problem is that we need to bootstrap pip, how do we install pip if
we need pip to install? We need to manually install all dependencies.
The pip dependency tree just for build/install requirements has 35
packages, we would need to manually install every single one of them to
be able to use pip in our workflow. This has been extensively discussed
here[2] and here[3]. The solution to create an install module had
been made in collaboration with PyPA (Python Packaging Authority)
members and is the correct way to move forward for such workflows.
Workflows that want reproducible install, ideal if you are deploying,
at this moment, also require the use of such tool, as pip does not
support them[4].

Due to typographical errors that occur, the usage of the pip
package, 'install', is dangerous.

Could you elaborate on this? I do not fully understand.

[1] analogdevicesinc/libiio#545 (comment)
[2] pypa/setuptools#2080
[3] pypa/setuptools#2088
[4] pypa/pip#5648

Cheers,
Filipe Laíns

And he finally replied today (14th of June):

Hi Filipe,

As far as I know, pip is included with python these days. No package manager is perfect, but I do not believe creating additional build/installation tools is the solution.

The typographical errors that I mention have to do with the issue known as 'typosquatting'. I specifically have install registered, so that somebody else does not register it and distribute malware when somebody typos 'pip install install otherpkg'. A few instances of this threat have been written about here: https://nakedsecurity.sophos.com/2017/09/19/pypi-python-repository-hit-by-typosquatting-sneak-attack/ and https://lwn.net/Articles/694830/.

Best,
Eugene

I sent my final reply and decided to open this request since the owner confirmed the name squatting and doesn't seem to be collaborative:

Hi Eugene,

On Sat, 2020-06-13 at 19:01 -0400, Eugene Kolo wrote:

Hi Filipe,

As far as I know, pip is included with python these days. No package
manager is perfect, but I do not believe creating additional
build/installation tools is the solution.

It isn't, it's a totally separate project, hence the need to bootstrap
the dependencies. You can believe whatever you whish, I provided you
enough information for you to understand the problem in depth. If you
think you have a better way to deal with our issue, feel free to let me
know, I would love to hear it.

The typographical errors that I mention have to do with the issue
known as 'typosquatting'. I specifically have install registered,
so that somebody else does not register it and distribute malware
when somebody typos 'pip install install otherpkg'. A few instances
of this threat have been written about here:
https://nakedsecurity.sophos.com/2017/09/19/pypi-python-repository-hit-by-typosquatting-sneak-attack/
and https://lwn.net/Articles/694830/.

While I appreciate you registering the name to prevent malware to be
distributed, 'install' is still a valid namespace and right now there
is a legitimate need to use it and I am requesting it. Currently your
use of the namespace is invalid, you should free it when requested.

Cheers,
Filipe Laíns

[FFY00]

I acknowledge I might have been a bit adamant in my last reply. I am a bit frustrated, especially since given the owner's comments on how he believes my project is wrong, even after I provided links to discussions which explore the issue I am trying to solve in depth. This is not an excuse, I should have worded it in a more friendly way.

[yeraydiazdiaz]

Hi @FFY00, there's a few elements at play here.

Firstly, at the moment of this writing, install has a new release with some functionality, therefore it cannot be considered invalid or namesquatting. While I appreciate you taking the time to contact the owner us moderators are obliged to make contact ourselves. In that spirit I'm tagging GitHub user @eugenekolo.

Secondly, if he does confirm he refuses the transfer, the PEP is clear about that:

Under no circumstances will a name be reassigned against the wishes of a reachable owner.

Thirdly, in those emails you've posted the owner does make a case that install is a dangerous project name and I agree, however, in these cases PyPI admins place the name in a blocklist, user namesquatting is not encouraged.

Finally, you argue that your project is a better fit to the name install as it implements PEP 517 and mention "collaboration with PyPA":

The solution to create an install module had
been made in collaboration with PyPA (Python Packaging Authority)
members and is the correct way to move forward for such workflows

However, there's no sign of involvement of the PyPA in your project. I would encourage you to reach out to the PyPA (I suggest the official Python forum) and discuss the project with them, including any potential names and subsquent actions.

I would very much like for other @pypa/pypi-moderators to comment on this. Personally, I think the best course forward is to place install in the block list and for @FFY00 to discuss his project elsewhere with the PyPA.

[FFY00]

Firstly, at the moment of this writing, install has a new release with some functionality, therefore it cannot be considered invalid or namesquatting.

This change was made after I created the request. The owner admitted to namesquatting and refused to collaborate, and as such, I do not believe this change was made in good faith. I have been very patient and cordial when dealing with this, up to the penultimate email, I have explained why the project is needed and why other alternatives are not usable, @eugenekolo simply dismisses it as "I don't agree" providing no arguments. I do not think this action is correct.

The package had no downloads until today, which now has 2.
https://pypistats.org/packages/install

And after I checked out the contents of the package, I cannot help to feel like this is a personal attack.

#!/usr/bin/python
import subprocess
import sys
import shlex
import os
import tempfile
import urllib.request

def _get_pip():
    fd, path = tempfile.mkstemp('_get-pip.py')
    urllib.request.urlretrieve("https://bootstrap.pypa.io/get-pip.py", path)
    subprocess.check_call([sys.executable, path])

def _check_pip():
    try:
        subprocess.check_call([sys.executable, '-m', 'pip'], stdout=subprocess.DEVNULL)
        return True
    except subprocess.CalledProcessError as exc:
        return False

def install(pkg, use_pep517=None, requirements=None, options=None):
    """Install packages dynamically in your code

    Args:
        pkg: Name of the package as a string, you can also use version specifiers like requests==1.2.3
        use_pep517: Optionally set to True or False to force --use-pep517/--no-use-pep517
        options: Arbitary list of options to pass to pip for installation
    """
    if not _check_pip(): _get_pip()

    cmd = [sys.executable, '-m', 'pip', 'install']
    
    if options and isinstance(options, list):
        cmd.extend(options)

    if use_pep517 is True:
        cmd.append('--use-pep517')
    elif use_pep517 is False:
        cmd.append('--no-use-pep517')

    pkg = shlex.quote(pkg)
    cmd.append(pkg)

    subprocess.check_call(cmd)

The package downloads pip and installs packages with it. I am perplexed seeing someone would engage in such behavior. I do not see any reason for him to do this other than spite.

"I believe package installation should be delegated to pip solely."

"No package manager is perfect, but I do not believe creating additional build/installation tools is the solution."

I can't......

About the PyPA involvement, I talked with @pganssle (sorry for tagging you like this, please let me know if you wish me to not do that in the future) and the outcome of the conversation was that we could have a standalone tool to build wheels and one to install them.
For the install step, https://github.com/pradyunsg/installer exists but there was a discussion on whether to have a CLI, and if so, what was the scope. In the initial discussion there was clear that there were several people against some of my requirements for the CLI, and so it was better to provide a suitable CLI for my needs in a separate project, hence https://github.com/FFY00/python-install.
For the build step, I created https://github.com/FFY00/python-build which is now in the process of being transferred to PyPA.

[eugenekolo]

Thanks for reaching out to me @yeraydiazdiaz.

I refuse the transfer. I am okay with either the package name being blocked, or for me to continue maintaining ownership of the package. The current functionality of the package is being used in a few projects of mine and may be useful to others too.

[yeraydiazdiaz]

@eugenekolo that doesn't make much sense. If we were to place the project name in the blocklist you wouldn't be able to use that code with that name thus breaking your own usage of the project.

Regardless you uploaded some code after the request was raised and now you're claiming you're actively using the code.

PEP 541 does not completely cover every possible claim case so we rely on the good will of the community to work together to resolve these issues.

[FFY00]

If I may, I would like to advocate against placing the name on the blocklist. The install package had not registered downloads until today, which tells me that the issue with people mistakenly calling pip install install something is not that much of an issue. It is still possible though, but if we have a project there worst-case scenario people will install that project. And finally, there is a real need for the namespace.

I just wanted to state this before any further discussion. I will now refrain from making any other comments (until I am directly addressed) and let you proceed with the conflict resolution. Thank you :)

[eugenekolo]

@yeraydiazdiaz Sorry for the misunderstanding. The code I've placed into the package is code I am using on other projects. It was added to the install package and will continue to be maintained there. Thanks for looking into this.

[yeraydiazdiaz]

@eugenekolo You registered the project in 2016 with no functionality and then you pushed a release with some code after the request was made in an attempt to keep the project name.

I understand you probably had plans for that project name in 2016 but the fact is you have not used it in four years. By pushing some code now, immediately after the PEP 541 request, and giving some vague reasons for it you're not showing a lot support for a process that's driven by volunteers such as myself.

From my point of view as a moderator install should be transferred to @FFY00 because it was name squatting. Other @pypa/pypi-moderators and admins can make a final decision on this matter, I will not comment further.

[theacodes]

I am in favor of install being on the blocklist.

[theacodes]

Tagging @pypa/warehouse-admins.

[ewdurbin]

As an admin, I'm +1 to adding to prohibited project name list.

[pganssle]

What is the argument for putting it onto the blocked list, particularly if Filipe is going to put a legitimate package there?

It's possible someone will typo it and it will accidentally install the extra package, but that's true of many things. That's really only dangerous if something malicious lives there.

I don't really think it matters very much, I think Filipe's package could easily be named wheel-installer or something (it's more likely to live in distro packaging scripts where "short and sweet" doesn't matter), but I'm not convinced that this is an actual security issue.

I am just not sure what the argument is for

[FFY00]

I don't really think it matters very much, I think Filipe's package could easily be named wheel-installer or something

It is currently only a wheel installer, but I wanted to keep the possibility of other types in the future. Much like https://github.com/FFY00/python-build. It is not crazy to think that in the future other package types could arise.
Anyway, even though I would really like for it to be called install, it is not a big blocker.

Similarly, I don't really understand the argument. I feel like this is being a little too conservative. We are preemptively trying to solve an issue that has no real data backing it up -- by this I mean no data supports that people are mistakenly running pip install install something or similar. Even if they were, I struggle to categorize it as a security issue.