Open mlouielu opened 3 years ago
I assume after enable environment, we can achieve some isolate build environment, but in README usage we cannot know the effectiveness of this environment.
(e.g.
poetry run python --version
can check Python version difference between system python & poetry shell python).We should add a PoC after enable environment make new user know what happen.
Indeed we do not have a helper to check for the validity. We should improve it.
But what does PoC stand for?
Proof of Concept (PoC), maybe like pkg-config --cflags <some_wide_spread_library>
and return -1 in devenv environment?
Correct me if I am wrong. You are talking about adding a description in README to explan how a new environment is in effect after enabling it (devenv use xxx
).
I was talking about an additional function / command / helper in devenv
that does the check, and the README can use it to describe the effect.
I think both approaches are OK.
Both are OK, borrow from poetry, poetry debug
will show current environment information like:
$ poetry debug
Poetry
Version: 1.1.7
Python: 3.9.6
Virtualenv
Python: 3.9.6
Implementation: CPython
Path: /home/louie/xxx/.venv
Valid: True
System
Platform: linux
OS: posix
Python: /usr
maybe devenv can print out information like above.
+1 to the additional function in devenv
that does basic check like poetry debug
. Besides, my gut feeling shows that kind of debugging function could be helpful and applied to initial tests like https://github.com/solvcon/devenv/blob/main/tests/test_init_var.sh .
Renamed the issue. Let's see when we can work on it.
I assume after enable environment, we can achieve some isolate build environment, but in README usage we cannot know the effectiveness of this environment.
(e.g.
poetry run python --version
can check Python version difference between system python & poetry shell python).We should add a PoC after enable environment make new user know what happen.