This would be instead of relying on path::Path everywhere. Would support strange file path encodings, but very likely too much work to want to bother (e.g. converting to CString may be an issue).

Would make Debian happy. Swapping nix for libc should be doable.

Otherwise figure out what needs to happen to update to the latest version (🎗️ and remove the block for Dependabot).

Either directly error out or shown in the error logging.

Need to use a custom Dockerfile based off of https://github.com/microsoft/vscode-dev-containers/blob/main/containers/rust/.devcontainer/Dockerfile to:

• Install newest Python
• Install pandoc
• Install Graphviz/dot
• Install doit
• Create virtual environment
• ... anything else dodo.py needs

To make sure doit is run appropriately.

Describe the bug
Encountering error running py due to pyenv installed and set to system

$ py
pyenv: python3.9: command not found

The `python3.9' command exists in these Python versions:
  3.9.2

Note: See 'pyenv help global' for tips on allowing both
      python2 and python3 to be found.

To Reproduce

1. Install pyenv
2. pyenv install 3.9.2
3. cargo install python-launcher
4. py

Tried export PY_PYTHON as per FAQ but version file does not exist if global not set:

head: cannot open '~/.pyenv/version' for reading: No such file or directory

So tried creating file with pyenv global but that also failed on the special string system:

Error parsing 'system' as an integer: invalid digit found in string

Expected behaviour
Opens system python 3.8 prompt

Screenshots

$ pyenv versions
* system (set by ~/.pyenv/version)
  3.9.2

$ py --list
 3.9 │ ~/.pyenv/shims/python3.9 
 3.8 │ /usr/bin/python3.8                 
 3.6 │ /usr/bin/python3.6                 
 2.7 │ /usr/bin/python2.7 

System Details (please complete the following information):

• OS: Ubuntu 20.04
• Shell: bash
• Launcher Version: 1.0.0

Should work, but need to start testing on Windows

Specifically for fish since that's the shell I use, but probably open to completions for other shells.

A lot of design thought is captured in #69.

For example:

1. Create a virtual environment
2. Rename a directory that's a part of the path to the python executable
3. Activate the environment
4. Try running py

You will get a ENOENT error due to $VIRTUAL_ENV being hard-coded to the old path in the activate script.

https://cli.rs/

Will require having a specific domain for the project (most likely Read the Docs) to act as the CNAME.

As requested by @mikeckennedy and @okken on https://pythonbytes.fm/episodes/show/221/pattern-matching-and-accepting-change-in-python-with-brett-cannon.

https://discuss.python.org/t/trying-to-come-up-with-a-default-directory-name-for-virtual-environments/3750

Basically let a file named .venv point to a virtual environment directory to act as a redirect to a specific virtual environment somewhere else (whether it be local or global).

From #22 :

https://docs.brew.sh/Acceptable-Formulae

To generate the Homebrew formula, there's a cookbook, class details, and can use ripgrep's formula as guidance. Also might want an alias like ripgrep for rg if "py" is not already taken.

"pip"

Can also link to characters:
https://www.compart.com/en/unicode/U+007C
https://en.m.wikipedia.org/wiki/Vertical_bar

https://www.compart.com/en/unicode/U+2502
https://en.m.wikipedia.org/wiki/Box_Drawing_(Unicode_block)

IMHO the help message should be respected irrespective of where it's specified on the command line.

https://crates.io/crates/comfy-table

https://crates.io/crates/cli-table

Discussed in #117

Specifically, document how to run the tests and what to do when pytest freaks out.

I installed Python 3.10 and now the sort order of the versions printed by py -0 is kind of weird:

Installed Pythons found by C:\WINDOWS\py.exe Launcher for Windows
 -3.9-64 *
 -3.8-64
 -3.7-64
 -3.6-64
 -3.5-64
 -3.10-64

I'm guessing you're going to have to parse the versions...

Hey, would it be possible to start tagging releases so that I can package this for arch? Bonus points if you PGP sign them 😉

No need to use {:?}.

https://github.com/actions/cache

E.g. how to speed up the building of cargo-audit. Maybe save the built binary and compare against https://github.com/rust-lang/crates.io-index/blob/master/ca/rg/cargo-audit? Or use cargo-download and check the source to see if it is faster than building cargo-audit from scratch?

And automate its updating upon release using scriv's API.

Potentially solved by #14 or #15

https://aur.archlinux.org/packages/python-launcher

From #77

https://codecov.io/gh/brettcannon/python-launcher

Should make what's happening a bit more obvious.

https://rust-cli.github.io/book/tutorial/packaging.html

E.g. get the fish shell to be able to provide auto-completions.

Some shells might get this for free via #24.

Would make it easier for folks who need some part of the functionality.

I was trying to use something like py -X.Y -c "import sys; print(sys.executable, end='')" to detect the location of a given interpreter, but the execution result for a non-existant interpreter makes it difficult to handle the output. It would be much easier if the launcher fails in a more script-friendly way.

Building for Apple Silicon on my x64 Mac:

# One-time
rustup target add aarch64-apple-darwin

# Every time
cargo build --release --target aarch64-apple-darwin
py -m release tarball --target aarch64-apple-darwin
gh release upload (py -m release version --tag) <tarball>

Once macos-11 becomes generally available as an OS on GHA, this can be added to the Release workflow.

Only worth it if redistributors would install it.

Might not be quite so useful thanks to PYVENV_DEBUG.

Output on Windows:

 -3.8-64 *
 -3.7-64
 -3.6-64
 -2.7-64
 -2.7-64

I.e. the Windows version of supporting default virtual environments.

https://www.python.org/dev/peps/pep-0582/

Basically if the launcher is named python and has a ../pyvenv.cfg, make it so it acts like a virtual environment. Would make creating virtual environments a bit lighter.

• VENV_REDIRECT variant in launcher.c, __PYVENV_LAUNCHER__ functionality of the macOS framework build launcher
• Might need switch off CLI additions -- i.e. -h, --list, and version specifier support -- in this situation to make this work
• Read ../pyvenv.cfg and its home and version keys to determine the Python executable to run
• Acts as a heavyweight "symlink" to the Python executable for the virtual environment
• Speeds up environment creation by not having to copy over entire Python installation on Windows (e.g. .pyd files)
• See/edit the site module to gain ability to specify virtual environment location (while maintaining the invariant on how to detect virtual environments as outlined in the venv module docs); probably making __PYVENV_LAUNCHER__ not be macOS-specific

Would need to verify that this is actually worth it on Windows before pursuing the work.

Hi there. I heard about this on PythonBytes the other day. Really enjoy the times they've had you on either that or Talk Python.

This tool sounds great. When working on Windows I have a batch script on my path that allows me to use pyv to create an environment, upgrade pip, install from requirements (or setup.py if it exists). I've really wanted something that would at least quickly activate an environment when using something like WSL, but never got around to looking into it.

I'm attempting to install this in Ubuntu-20.04 WSL2 (on Windows 10 Pro 19042.804). I've only used cargo a couple of times, but had just installed it fresh this time. Looks like cargo version 1.46.0.

Any thoughts?

(btw - thanks so much for all you do)

$ cargo install python-launcher
    Updating crates.io index
  Installing python-launcher v0.14.3
   Compiling libc v0.2.86
   Compiling cfg-if v1.0.0
   Compiling autocfg v1.0.1
   Compiling proc-macro2 v1.0.24
   Compiling log v0.4.14
   Compiling lazy_static v1.4.0
   Compiling unicode-xid v0.2.1
   Compiling syn v1.0.60
   Compiling memchr v2.3.4
   Compiling bitflags v1.2.1
   Compiling getrandom v0.2.2
   Compiling smallvec v1.6.1
   Compiling scopeguard v1.1.0
   Compiling serde v1.0.123
   Compiling regex-syntax v0.6.22
   Compiling gimli v0.23.0
   Compiling unicode-segmentation v1.7.1
   Compiling adler v1.0.2
   Compiling serde_derive v1.0.123
   Compiling termcolor v1.1.2
   Compiling object v0.23.0
   Compiling rustc-demangle v0.1.18
   Compiling strum v0.20.0
   Compiling exitcode v1.1.2
   Compiling instant v0.1.9
   Compiling lock_api v0.4.2
   Compiling thread_local v1.0.1
   Compiling heck v0.3.2
   Compiling aho-corasick v0.7.15
   Compiling num-traits v0.2.14
   Compiling num-integer v0.1.44
   Compiling miniz_oxide v0.4.4
   Compiling quote v1.0.9
   Compiling regex v1.4.3
   Compiling parking_lot_core v0.8.3
   Compiling signal-hook-registry v1.3.0
   Compiling mio v0.7.9
   Compiling time v0.1.43
   Compiling atty v0.2.14
   Compiling nix v0.19.1
   Compiling addr2line v0.14.1
   Compiling parking_lot v0.11.1
   Compiling signal-hook v0.1.17
   Compiling uuid v0.8.2
   Compiling os_type v2.2.0
   Compiling chrono v0.4.19
   Compiling crossterm v0.19.0
   Compiling backtrace v0.3.56
   Compiling stderrlog v0.5.1
   Compiling toml v0.5.8
   Compiling strum_macros v0.20.1
   Compiling comfy-table v2.1.0
   Compiling human-panic v1.0.3
   Compiling python-launcher v0.14.3
error[E0658]: use of unstable library feature 'bool_to_option'
   --> /home/ben/.cargo/registry/src/github.com-1ecc6299db9ec823/python-launcher-0.14.3/src/cli.rs:146:24
    |
146 |     venv_path.exists().then(|| {
    |                        ^^^^
    |
    = 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.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `python-launcher v0.14.3`, intermediate artifacts can be found at `/tmp/cargo-installEVaE2b`

Caused by:
  build failed

https://github.com/actions-rs/install

Should simplify the GitHub Actions greatly while making them faster by avoiding ever having to build the tools.

https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/configuration-options-for-dependency-updates

• Cargo
• Python
• GitHub Actions

https://www.python.org/dev/peps/pep-0514/

Describe the bug
Fails to compile on docker image ubuntu:latest.

To Reproduce

cargo install python-launcher

   Compiling python-launcher v0.15.0
error[E0658]: use of unstable library feature 'bool_to_option'
   --> /root/.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`.

Expected behaviour
The build to succeed.

System Details (please complete the following information):

• OS: ubuntu:latest
• Shell: bash
• Launcher Version: latest

rust (1.47) & cargo (0.47) installed via apt-get. Note it works if one installs the latest rust via https://rustup.rs.

https://blog.rust-lang.org/2020/11/19/Rust-1.48.html#easier-linking-in-rustdoc

E.g. --json flag for JSONified --list output. Would make consuming data from the CLI easier (e.g. for Nushell).

Exists for the Windows launcher: https://www.python.org/dev/peps/pep-0397/#configuration-file.

A key thing to remember is should not get to the point that you're using this to alias specific interpreters, just making it easier to specify constraints on what kind of interpreter you need and then letting the launcher pick for you. Otherwise you should just launch the specific interpreter you want.

• Customized commands?
  • Want a better format like TOML?
  • Want a way to override/specify things, e.g. wanting a framework build on macOS?
    • Aliasing? E.g. 2.7-framework for
      /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python?
    • Just provide a way to specify a specific interpreter for a specific version?
      E.g. 2.7 for
      /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
    • What about implementations that don't install to e.g. python3.7 like pypy3?
      • Need more than just being able to alias pypy3 to its Python version?
  • How should the config file search work?
    • Pre-defined locations?
    • Walk up from current directory?
    • XDG base directory specification?