Traverse up from the cwd to look for `.venv` virtual environments about python-launcher

[brettcannon]

Looks like std::path::Path.ancestors will give an iterator that walks up. Use of std::path::Path.join should make it easy to join the relative path to .venv/bin/python to each portion. Then using std::iter::Iterator.find should make it easy to use std::path::Path.is_file to search appropriately.

let relative_venv_path = Pathbuf::from(".venv/bin/python");  // Not sure if this is platform-agnostic.
let containing_path = std::env::current_dir().as_path().ancestors().find(|dir| dir.join(relative_venv_path).is_file());

[mikeckennedy]

Hi @brettcannon Very cool, thank you for thinking of us. What a neat feature.

[brettcannon]

@mikeckennedy @okken This change is in 0.15.0, so please give it a try and let me know how it goes!

[mikeckennedy]

Will do! And I'll share it on Python Bytes as an update.

[mikeckennedy]

Oh, can't get it to install on macOS for some reason:

error[E0658]: use of unstable library feature 'bool_to_option'
   --> /Users/michaelkennedy/.cargo/registry/src/github.com-1ecc6299db9ec823/python-launcher-0.15.0/src/cli.rs:164:29
    |
164 |         venv_path.is_file().then(|| venv_path)
    |                             ^^^^
    |
    = note: see issue #64260 <https://github.com/rust-lang/rust/issues/64260> for more information

error: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
error: could not compile `python-launcher`

To learn more, run the command again with --verbose.

No complaints. Just FYI. :)

[brettcannon]

@mikeckennedy upgrade your version of Rust to 1.50.0 or newer.

Duplicate of #82 .

[mikeckennedy]

Thanks Brett. Crazy, I had installed Rust from Homebrew just when I posted this. But it was 1.49. It updated to 1.50 today and the install worked. :)

I tested the feature out on my system but couldn't get it to work. Maybe I'm doing it wrong but it could be not using the default .venv name. Is this a real problem or did I get my system into a wonky state?

In shell profile: export VIRTUAL_ENV="venv"

In terminal:

Venv Dir: /Users/me/github/repo_name/src/package_name/venv
CWD: /Users/me/github/repo_name/src/package_name/package_name/bin/reporting
Command: py summary.py

Error message: venv/bin/python: No such file

[brettcannon]

So your VIRTUAL_ENV export cheat broke expectations. 😄 That environment variable is set by the virtual environment activate script. So by setting it to venv it causes the launcher to simply look in the venv directory for venv/bin/python. Since you don't have that in your reporting/ directory it's failing due to it not actually existing (you can run with logging turned on to get a bit more detail about how the search is going). That's why the docs at https://github.com/brettcannon/python-launcher#py-any-version say "Use ${VIRTUAL_ENV}/bin/python immediately if available" and doesn't mention traversal.

So you have two options. One is to set VIRTUAL_ENV to an absolute path (either via activate or manually). The other option is to put your virtual environment in a directory named .venv, not venv like you have in your example (I wasn't kidding on the podcast that it wasn't configurable for the directory name 😁 ), then the traversal semantics you asked for will work.

But my question to you is what would the docs need to say to make it clearer that what you tried isn't what is intended?

[mikeckennedy]

Ahhh, sorry about that. I thought the purpose of VIRTUAL_ENV was to allow me to specify a name other than .venv, such as venv or .env for example.

I'm not sure the docs were unclear. I honestly skimmed them with my preconceived notion. :)

[brettcannon]

BTW if you want a way to specify the directory name like that then I would encourage you to open an issue on bugs.python.org to let venv default to using an environment variable when set (e.g. PYTHONVENVDIR or somthing). Then the Launcher could read that to determine what directory name to check under. And the reason I'm suggesting solving this upstream is all of it solves potential typo problems.

[mikeckennedy]

Interesting, that's a good idea. Thanks Brett.