[HN Gopher] Use `Python -m Pip`
___________________________________________________________________
Use `Python -m Pip`
Author : behnamoh
Score : 39 points
Date : 2022-07-19 19:17 UTC (3 hours ago)
(HTM) web link (snarky.ca)
(TXT) w3m dump (snarky.ca)
| valbaca wrote:
| Where this conversation is inevitably going to go:
| https://xkcd.com/1987/
| [deleted]
| sidpatil wrote:
| Contrast with https://xkcd.com/353/.
| revskill wrote:
| I have many friends, who's not working as a programmer, but treat
| programming as a side job only. And what i observe the common
| theme from them is, they don't mind software engineering
| practice. What made me confusing and i think, Python actually did
| a good job at bringing programming to mass audience.
|
| What's not going good, is, in Python, software engineering
| practice is not something to be a huge concern, so end-user
| hardly learn the same way about how to do thing "correctly".
|
| That made me sad though.
| whichquestion wrote:
| Pyenv[1] solves the multiple versions of python problem in my
| experience. You can install the version of python you want and
| then can set that version globally, per directory, and then use
| that versions pip or take it further and use a virtualenv/poetry
| shell.
|
| 1: https://github.com/pyenv/pyenv
| romeoblade wrote:
| This!
|
| I use a combination pyenv, direnv and poetry for my projects.
| sph wrote:
| Not to be confused with pipenv!
| cmcconomy wrote:
| I wish there was a way to lock the global python so you couldn't
| install packages to it by accident
| dragonwriter wrote:
| On unixy systems, won't the system Python usually require
| root/sudo to install packages, whereas the ones in your
| environments will be owned by a less-privileged user?
|
| And on Windows, you may have a globally installed Python
| (though there is little reason to have one instead of the Py
| launcher), but even if you do it's not a system Python that
| system components are relying on.
| __mharrison__ wrote:
| You can do this in UNIX systems by dropping a line like this in
| your ~/.bashrc
|
| . /home/matt/envs/menv/bin/activate
| Thrymr wrote:
| (2019) Not that anything has fundamentally changed, there are
| just more other ways to install and manage python packages.
| woodruffw wrote:
| This is great advice. To tack on:
|
| Python has had built-in virtualenv support since 3.3[1], meaning
| that you can do this: python -m venv env/
|
| ...on any version of Python released in the last decade and get a
| reasonable virtual environment. To go one step further, you can
| also have `venv` automatically bring `pip` and `setuptools` to
| their latest versions: python -m venv
| --upgrade-deps env/
|
| ...which you should almost always do, since the versions bundled
| with your Python distribution are likely to be behind the latest.
| CobrastanJorji wrote:
| Yeah, I strongly advise ALWAYS using a virtualenv for any
| Python project. It's pretty much always a good idea.
| jonatron wrote:
| If you're on Debian/Ubuntu, you'd first need to install
| python3-virtualenv. It does say that though IIRC, if you try
| without it installed.
| [deleted]
| woodruffw wrote:
| Almost! `python3-virtualenv` is virtualenv, the third-party
| tool that ultimately inspired `venv`. `python3-venv` is the
| Ubuntu/Debian breakout package for `python -m venv`.
|
| TL;DR: Install python3-venv, not python3-virtualenv.
|
| (Ubuntu and Debian's decision to break out core parts of the
| Python standard library has been an unending source of
| problems. PEP 668[1] is an in-progress effort to better
| categorize these kinds of distro changes and improve the user
| experience around them.)
|
| Edit: I should also qualify: virtualenv is still maintained
| and useful; venv is contains the subset of virtualenv's
| functionality that 99% of users use.
|
| [1]: https://peps.python.org/pep-0668/
| jwilk wrote:
| Beware that "python -m" is insecure in untrusted cwd:
|
| https://bugs.python.org/issue33053
|
| E.g.: $ echo 'import os; os.execvp("cowsay",
| ["-", "pwned"])' > pip.py $ python -m pip --version
| _______ < pwned > ------- \ ^__^
| \ (oo)\_______ (__)\ )\/\
| ||----w | || ||
| gammalost wrote:
| Python is a fun language but the ecosystem around it is horrible.
| It's a shame. I just want to pip install like I would a package
| manager
| newuser4321 wrote:
| I think you mean the package management rather than the
| ecosystem. For all its failings, the python ecosystem (for
| machine learning / data science in particular) is unmatched,
| which is why python is so popular.
|
| As a "professional" python user (who got there in a roundabout
| way), I'd say the biggest problem with package management is
| all the conflicting advice and different ways to accomplish the
| same thing (there are other problems, but they are
| surmountable). Once you get a workflow down, it ends up being
| pretty easy to set up and manage an environment for a given
| project. Not that it's perfect, but I think a lot of the
| stereotypes about how bad it is come from how bad it appears as
| you try to converge on a setup that works for you.
| eslaught wrote:
| To be honest, I don't see how you can give this advice. A
| couple of the most popular package management systems for
| Python are very obviously deficient (and sigh, these are
| usually the ones I get stuck working with, due to outside
| constraints).
|
| A classic example is version pinning. Rust has Cargo.lock,
| Ruby has Gemfile.lock. Python? It depends on which one of the
| multitude of options you pick. But at least a couple of the
| most popular ones basically don't do this (pip) or do this in
| a hacky, ugly way that makes you want to tear your hair out
| (Conda). As a result, at least in the projects I work on,
| people tend to skip this.
|
| I hope it should be obvious what bad things can happen if you
| don't pin your dependencies, but for the uninitiated: I'm
| talking about things like projects breaking inexplicably
| after 6 months because you rebuilt some Docker container and
| something or other got upgraded and is now incompatible.
|
| Beyond the technical issues, there's a human engineering
| problem of getting everyone on the same page about the right
| processes, and Python makes that _vastly_ harder by not
| having a One True Solution that everyone just uses.
| gjvc wrote:
| "pip freeze" generates a versioned list of packages to
| install in the same format as requirements.txt -- in this
| example below i've called it versions.txt
| if versions.txt exists and is newer than requirements.txt:
| pip install -r versions.txt else pip
| install -r requirements.txt pip freeze >
| versions.txt
| thrashh wrote:
| The reason for the conflicting advice is because people keep
| making new package managers that still suck overall. Like
| they fix one major package manager problem and somehow
| neglect the other 60% of problems.
|
| So you end up with all these different Python package
| managers that are all good at individual different things but
| no single package manager that is good at all of the things.
|
| I swear that is a major problem with most libraries or tools
| that people make. It's like people fix their pet peeve but
| forget that the whole picture matters way more.
| bloblaw wrote:
| I remember when Perl was more popular generally than Python
| (late 90's and early 00's), and Perl espoused the mantra of
| (There is more than one way to do it: TIMTOWTDI).
|
| As a tongue-in-cheek reaction, Python espoused "TOOWTDI", or
| There's Only One Way To Do It :)
|
| reference: https://wiki.python.org/moin/TOOWTDI
|
| The problem is, when it comes to the Python package
| management ecosystem, there are SO MANY ways to do it. And
| they aren't equal and require a deep understanding of each
| tool to select the correct choice.
|
| It _is_ a problem for Python, although I often regrettably
| see it dismissed as not a true issue because
| $latest_package_management_system fixes it.
|
| Python has allowed me to be profoundly productive in many
| ways, but this is a huge sore spot for the Python ecosystem.
| jmcgough wrote:
| As someone two months into their first python job - the
| ecosystem is solid for ML / data science, but there's a lot
| of places where it's painfully lacking.
|
| I hate the most popular ORM (sqlalchemy) and alembic has a
| lot of footguns: for instance, if you autogenerate a
| migration where you change a table name, it will try to drop
| the old table and create a new one.
|
| In web dev a lot of the OSS community has moved on to more
| appropriate or exciting languages, so the tools I'd normally
| reach for frequently are OSS projects that haven't been
| maintained in seven years.
|
| As for pip: it needs a major version bump that creates a
| lockfile, or it needs to be intentionally sunset. It's easy
| for a beginner to start using (part of why it's heavily
| used), but extremely dangerous because of the lack of
| guarantees. I wish it didn't have as big of a footprint as it
| does.
| m_mueller wrote:
| agreed on the lockfile. we use pip-tools to achieve this,
| which gives the `pip-compile` command. a Makefile is tying
| together the different development and build workflows we
| have, such that it can be executed both locally as well as
| in our CICD build server. complexity is manageable, but
| it's roughly comparable to a compiled language if you want
| locked-down reproducible builds (which I recommend for
| anything production grade).
| wombatpm wrote:
| Much prefer the Django ORM, which is a pain to use if you
| are not building web apps
___________________________________________________________________
(page generated 2022-07-19 23:00 UTC)