Existing venv folder in current directory causes crash

[AtomsForPeace]

Expected Behavior

Just trying it out and started with the huak activate command. I think based on the .toml output that it finds my old venv that I didn't want to delete and crashes. Maybe a hint that it won't work with a venv folder in the current directory would be better?

Actual Behavior

Get a crash

Steps to Reproduce

Using Python 3.9.7, run pip3 install huak, run huak activate.

Version

huak 0.0.18

System Information

Python 3.9.7, Linux Mint 19.3 Tricia

.toml file name = "huak"

operating_system = "Linux 19.3 (tricia) [64-bit]" crate_version = "0.0.18" explanation = """ Panic occurred in file 'src/huak/lib.rs' at line 1196 """ cause = "failed to parse version from /home/adam/Projects/recipe/backend/old_venv/pyvenv.cfg" method = "Panic" backtrace = """

0: 0x55b1e4819e5d - <huak::VenvConfig as core::convert::From<&std::path::Path>>::from::hc7af3c4da1849e90 1: 0x55b1e4817589 - huak::PythonEnvironment::new::h37b75af47fb65d7a 2: 0x55b1e4813013 - huak::Workspace::current_python_environment::he0e86954e017a74f 3: 0x55b1e47fbea4 - huak::ops::activate_python_environment::hef32c7b5117831ca 4: 0x55b1e4790f66 - huak::cli::Cli::run::h68c972942c3bff49 5: 0x55b1e47a73b4 - huak::main::h643aab1a3e6922a0 6: 0x55b1e47ab553 - std::sys_common::backtrace::__rust_begin_short_backtrace::hbb47f52372205bb1 7: 0x55b1e47b1f89 - std::rt::lang_start::{{closure}}::he7e398131cce4a7d 8: 0x55b1e4b91adc - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h203afb3af230319a at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/core/src/ops/function.rs:287 - std::panicking::try::do_call::hf68e87013b70f3c5 at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/std/src/panicking.rs:483 - std::panicking::try::h040ea8f298390ba2 at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/std/src/panicking.rs:447 - std::panic::catch_unwind::h1e17b198887a05fa at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/std/src/panic.rs:140 - std::rt::lang_start_internal::{{closure}}::hfb902d8927e51b86 at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/std/src/rt.rs:148 - std::panicking::try::do_call::h354e6eb41f2e7d42 at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/std/src/panicking.rs:483 - std::panicking::try::h4a39749cd018228c at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/std/src/panicking.rs:447 - std::panic::catch_unwind::h30bce83b8de61cca at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/std/src/panic.rs:140 - std::rt::lang_start_internal::h8f7e70b1a2558118 at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/std/src/rt.rs:148 9: 0x55b1e47a7a15 - main 10: 0x7f66ca853c87 - __libc_start_main at /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310 11: 0x55b1e478be02 - 12: 0x0 - """

PS. Github doesn't seem to allow you to attach .toml files.

[cnpryer]

Interesting. I'll try to reproduce this today. Thanks!

[cnpryer]

Ah

cause = "failed to parse version from /home/adam/Projects/recipe/backend/old_venv/pyvenv.cfg"
method = "Panic"
backtrace = """

That'll do it. So huak is trying to pull the version of the Python interpreter from this. I think this might not panic on master if you want to try that. Otherwise I'll get this fixed.

Thanks for the report. This is a good one.

[cnpryer]

Also if you don't mind, could you share the top-level dir tree? Do you have multiple venvs? It's going to find one of them by locating a pyvenv.cfg and use that.

[AtomsForPeace]

I do have multiple venvs but only one in that directory.

By top-level dir tree do you mean what's listed in that folder? if so: app.py cli.py coverage/ old_venv/ pycache/ recipe.sqlite src/

[cnpryer]

yea so it's going to use old_venv. are you expecting different behavior? any chance you could share the contents of its pyvenv.cfg?

[AtomsForPeace]

So I pip installed the local repo on master and it throws no error.

[cnpryer]

So I pip installed the local repo on master and it throws no error.

Do you mean cargo?

[AtomsForPeace]

The pyvenv,cfg looks like this: home = /usr implementation = CPython version_info = 3.10.0.final.0 virtualenv = 20.8.1 include-system-site-packages = false base-prefix = /usr base-exec-prefix = /usr base-executable = /usr/bin/python3.10

Should the activate command use the old_venv? In between reporting the issue and now I've tried to remove pyvenv completely so that could add some confusion.

[AtomsForPeace]

So I pip installed the local repo on master and it throws no error.

Do you mean cargo?

I cloned it, ran cargo build and then switched to my python project and ran pip install -e ../huak

[cnpryer]

The pyvenv,cfg looks like this: home = /usr implementation = CPython version_info = 3.10.0.final.0 virtualenv = 20.8.1 include-system-site-packages = false base-prefix = /usr base-exec-prefix = /usr base-executable = /usr/bin/python3.10

Should the activate command use the old_venv? In between reporting the issue and now I've tried to remove pyvenv completely so that could add some confusion.

Yea this is what I thought. pyvenv.cfg isn't really well standardized across different platforms and with different distributions I think. I need to look into this more.

I cloned it, ran cargo build and then switched to my python project and ran pip install -e ../huak

I haven't done this. Usually I just uninstall my pip install and cargo install the master to use master. Try which huak to see if its the pip install or if its from the cargo global.

[AtomsForPeace]

The which huak gives me /home/adam/.cargo/bin/huak which I guess is expected.