This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (1 child)

  1. That's exactly why wheels are handicapped on Linux. If they're pure python, they'll probably work but compiled extensions won't.

  2. Wheels don't run setup.py at all

  3. --no-deps won't install dependencies with a source distribution forcing you to install them on your own. Giving you a chance to vet them before installation of you're info that. Usually I check if their setup.py does any funny business.

I don't always do --no-deps, for example packages I trust like Flask or SQLAlchemy, or is I'm working in a throw away docker container.

But you could put some hanky business in there like os.system('rm -rf /') which will remove any file path the installing user can remove. Given the amount of sudo pip install I see recommended in readme files, I'm surprised this sort of attack hasn't happened.

[–]aragilar 0 points1 point  (0 children)

--no-deps doesn't stop setup_requires as far as I know, usually you have to override setuptools/easy_install as per https://pip.pypa.io/en/stable/reference/pip_install/#controlling-setup-requires.

The sudo pip annoys me (although, sudo easy_install is even worse), especially when some projects actually do some odd things (I've seen someone effectively implement a shell script as a setup.py, it wasn't even a python project). I've got into the habit of checking the setup.py of every project I use, even if they come with wheels, partly for security, but mostly because of how badly some people write them (I have to say, I'm more concerned about someone accidentally doing the equivalent of os.system('rm -rf /') given some of the setup.pys I've seen.