Gregory's Server(This thought brought to you after several lost minutes where it turned out I had the wrong PATH and that’s why tests were failing in weird ways)
|
19 comments
 @simon That is one of the benefits of running in a self-contained dev container. You can be sure that your system (global installs, env vars, etc) don't interfere with the dev environment. I always wondered if there is an iteration on python's venv concept where the venv would also restrict filesystem paths, env vars, and more. @simon What was the specific problem? I honestly don't remember the last time I had a PATH problem, but I'm sure I have a blind spot here.  @brettcannon for the problem I just had it was that thing where I create a brand new pipenv environment and install pytest into it, but when I run pytest it runs a globally installed binary instead - I had to quit out of and re-enter the environment to get the environment-local pytest to run (which could then see my dependencies) It reminded me how much knowing what a PATH is matters for figuring out errors like that  @simon @brettcannon also it's hard to describe the common new-user failure mode, which is "something doesn't work, or it behaves weirdly with tool X, so I install tool Y because maybe that one works". X, Y, Z, A, B C all append a little bit of stuff to your ~/.zshrc or whatever, scattering $PATH configurations into a bunch of different locations that make every IDE and terminal function differently, and even if it's all eminently comprehensible, unwinding is a tedious nightmare @simon So I take it you don't run pytest via `python -m pytest` but instead via `pytest`? @brettcannon huh... that's the case, but now you mention it there's no reason I shouldn't start a habit of using "python -m pytest" instead @dabeaz @brettcannon I've upgraded all of my cookiecutter templates to use "python -m pytest" instead of just "pytest" now: https://github.com/simonw/python-lib/issues/9  @simon @dabeaz @brettcannon Python‘s. venv is like Marvel‘s Multiverse. No one ever is positively surprised by any of it.💁🏻♂️ What if Python shipped a standard library module that diagnosed this stuff in as much detail as possible for you? So you could run something like: python -m debugenv And it would print out a whole bunch of useful stuff about what your PATH is, your Python path, what version, any other versions it can find in common locations, if you are in a virtual environment, links to tutorials that will explain more - that kind of thing @simon I wrote something that does a little bit of this: https://github.com/nedbat/pydoctor @simon something along these lines is quite literally on my plate for the next few weeks of free time at work  @simon I started to write that once. The root problem is that the Python run time could be anywhere on the machine, but is likely at a few know places. Or it is at 130 places because that is how many vens are on the machine. @simon This would have saved me two to three hours today. it really needs to come to life. @simon I’m sure you’ll hear about a number of these tools today, but for work I made a less Python-specific environment report tool, which handles things like HPC system modules, pip, conda, $PATH: https://github.com/minrk/envreport . It errs on the side of “entirely too much information, send this to support,” probably not very manageable for most directly affected individuals. |
@simon The truth is, "check out the repo and run it" is an open problem in every programming language I know.
I got a python repo to run today, windows + git bash + jetbrains, and I was astonished. This has, literally, never happened to me before.
I live usually in java/kotlin, and there, the situation is equally perilous.
I have some sense that rust's cargo is better, but no proof beyond a single repo.