4 ms·

People complain lot about python packaging, have complicated setups to work with it, and invent new tools all the time. In the meanwhile, I just use vanilla pip

• dagw 3y ago
  If you're targeting just one version of python, on just one version of one OS, only running on a computer you control, then there are very few problems. The problems only really come when you remove one or more of the above constraints.
  • stuaxo 3y ago
    True, though I'm not sure .venv is a solution for any of those problems.
  • zokier 3y ago
    Being conservative with library and language feature choices helps a lot too
  • Doxin 3y ago
    Multiple python versions still isn't exactly hard with pip+venv. If you want a different python version for your venv, just use that python version to install the venv. Package repositories not providing the python version you need? Python is surprisingly easy to compile from source. Different OSes is a bit more annoying. I tend to just get VMs involved and do the build on the target OS.
• eltradero 3y ago
  Thumbs up, plus a well-maintained Makefile that I share among my projects. Never had any issues. Github matricx test runners ensure that everything works across platforms, Python and dep versions, ...
  • jrib 3y ago
    what do you put in your Makefile?
    • eltradero 3y ago
      make env = create environment and pip install editable mode (I typically list dev and test dependencies as optional-dependencies in pyproject.toml) make test = test, coverage, ... make docs = sphinx-build ... make release = build, twine, ... I try to keep things simple.
• benreesman 3y ago
  It gets really hard in accelerated computing, where there are a number of stories that are kinda ok (vanilla virtualenv with some hand-rolled special casing can get you like, off the ground, conda/miniconda are workable in some scenarios, Poetry can kinda do it), but it just gets really, really hard if performance matters. pip’s depset builder is also non-deterministic up to its stated capabilities: at the stated capabilities dependency resolution is IIRC exactly NP-hard, it’s in that “you’re using a SAT solver but it will usually be fine” neck of the woods which is why more modern stuff (including I think apt and other Debian-adjacent stuff) use solvers now. You can limit the use of version ranges, you can pin like Bazel does with depsets (usually). This is why running pip repeatedly often solves the problem: you rolled a better character and/or it was hinted by a previous run. Docker and friends can help but you get the usual Docker headaches, especially with qemu in the mix. I find OrbStack is just a strictly better option everywhere I’ve tried it, but docker over emulation/virtualization is rarely any kind of fun in the presence of accelerators. So, I want to run an LLM or SD or some other now common thing, but I’ve got an NVIDIA box on x86_64-linux and a Mac on aarch64-darwin. What do I do? That sounds reasonable right? Good luck. I went the whole way with Nix last time, and it solved lots of other problems (and in that world, problems stay solved until you are compelled to do a non-trivial update), but Python was still a nightmare. This time I’m trying flox: and so far it’s been friggin awesome. It’s a little rough here and there for advanced users, but flox install pip, pip install torch/etc, and go? That works. On like, 7 os/cpu/accelerator combinations I’ve tried. It probably sounds like I’m on their payroll but I’m legitimately just a very, very happy user who posts on HN in between excellent interactions with my bedrock env tool now. I hang out in their Slack but I don’t work there.
• mannykannot 3y ago
  The problem I had was that the plethora of current and former alternatives out there obscured that fact that this was a straightforward and adequate option.
• linsomniac 3y ago
  I've been doing largely the same as you up until just about a month ago, and maybe once a year I'd have to track down and deal with breakage of my environment because of it. Things periodically get into a weird state for reasons I don't understand. About a month ago I set up a "homedir python" using pyenv, to hopefully solve this problem once and for all. So far it seems to be working great. Though for projects I've been playing with poetry and rye the last year, basically just as syntactic sugar over venv, mostly just to try them out. They work fine, though I don't understand why "rye shell" is being deprecated.
  • FartinMowler 3y ago
    Rye is replaced by UV. See https://lucumr.pocoo.org/2024/2/15/rye-grows-with-uv/ https://lucumr.pocoo.org/2024/2/15/rye-grows-with-uv/
• wodenokoto 3y ago
  That's because you don't need different versions of python. The author needs to test his stuff against different versions, including ARM and intel versions. I'd say it is a good idea to pin python version in your project just like you'd pin any library - after all, there are changes to the standard library all the time. But how to do that in practice. Fuck me if I know a good way.
  • zelphirkalt 3y ago
    Can try with a pinned container image.
• woodrowbarlow 3y ago
  pip + venv with requirements.txt is 90% of the way there. the bare minimum most people need on top of this is some form of lockfile. without this, builds are not reproducible. it's frustrating to ask users to install an extra tool (like poetry or whatever) when python comes with almost everything. at least `pyproject.toml` is standardized in a PEP, so you don't have to force users to choose a specific tool to resolve it.
• zelphirkalt 3y ago
  Works until you need a reproducible setup that will alert you, if anything in your dependencies chances.