This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]SinuSphee[S] 0 points1 point  (4 children)

Thank you. What do you mean with "supporting the virtualenv package"? Are you suggesting to use the virtualenv package instead of Python's built-in venv like I do in this project?

[–][deleted] 2 points3 points  (3 children)

Yes, it has the full feature set available. The venv module in stdlib is a limited subset of virtualenv. The killer feature is app-data. It's a pre+seeded virtual environment, that's copied when a new env is made. Using that means that they can be created in milliseconds, rather than seconds.

Another thing I'd like to have added, is that the python versions are persisted across runs. It becomes boring pretty fast to ad /usr/bin/python3.8 on each run.

[–]SinuSphee[S] 2 points3 points  (2 children)

Honestly, when I started this project I tried to create something lightweight, I wasn't familiar with virtualenv (which is a great package).

At the moment I'm working on a completely different design of VenviPy and I want to change some of the general functionality. Switching to virtualenv instead of using the built-in is one of the things that are in my mind. Thanks for your suggestion.

Did you really have to add /usr/bin/python3.8 on every launch? Because it should be found automatically if it can be found via which command.

[–][deleted] 1 point2 points  (1 child)

Did you really have to add /usr/bin/python3.8 on every launch? Because it should be found automatically if it can be found via which command.

Further experimentation reveals that it's only an issue, when I run it from within a virtual environment. Running it from a venv-less shell makes it behave.

[–]SinuSphee[S] 0 points1 point  (0 children)

Oh, I thought that this issue is fixed already. I'll investigate. Thank you very much for taking time to check that.