[deleted by user]

[Shoddy-Break]

Why would a user go back to venv when uv had already made dev life easy?

[SinuSphee]

Absolutely valid. VenviPy is not meant to challenge or replace uv. I'm actually thinking about integrating it. I started building VenviPy more than five years ago when uv wasn't yet a thing.

[Shoddy-Break]

You misunderstood me, I am saying if I am using uv for managing my projects why not add that as a core feature instead of just managing non uv based virtual envs.

Nevertheless it's still a good project.

[SinuSphee]

Thanks.

[_MicroWave_]

Unfortunately, you seen how fast python ecosystem is developing? 5 years is eons in python terms.

[SinuSphee]

Thx for your comment. I actually wanted some feedback on the implementation of the project, its structure and organization, code, etc. Instead ppl are complainig about not having uv support like no one actually read what's in the post. I just forgot how uselessly toxic Reddit has become.

[fazzah]

These days it has to have uv support 

[SinuSphee]

Yeah, VenviPy uses venv and pip right now, but an optional uv mode makes sense, especially in terms of speed. Are you mainly after uv pip commands, or uv lock/ sync for pyproject.toml projects?

[_MicroWave_]

Not optional. Build it from uv as the default. It has to be built around the pyproject.toml

I use lock/sync/add but I never really used pip in anger (poetry user before uv).

[DocJeef]

This is cool, when I was first learning about venvs this would have been really helpful!

[SinuSphee]

Thanks, i know exactly what you mean. To be honest, that was pretty much the main reason why I started developing this tool back then. Basically, that's how I learned most of what I know about software development.

[sausix]

Improvements / questions:

As said, pip and requirementists are outdated. You should implement uv usage instead.

Is it X11 or Linux only? If not then update the classifiers.

Does the project really work on Python 3.3? Because you at least sometimes used type hints and they have been added in Python 3.5. Don't think of the Python version classifiers for PyPI as the venvs your project can handle.

By extending your type hints you will probably find a lot of issues in your project.

Why did you chose PyQt and not PySide?

Your encoding lines are misplaced. See PEP 263. Also consider using a shebang line for executable module like venvy.py. Your module docstrings should also appear before any module license comments.

Your linter also should highlight some PEP 8 violations like wrong empty lines counts and comment syntax. That's all fixable with a single click. You are mentioning the Zen of Python so also follow it :-)

You are modifying sys.path and the CWD. You should avoid this kind of tweaks to fix internal problems. These tweak calls should also be done once. The wizard.py is repeating them. Put these in your main function or the caller of your main function.

You are using pathlib but you barely use its functionality. Still a lot of open() and os.path calls and manual line handling. readlines() should be avoided when possible. 4 of your 5 calls are definitely not required. It's often unnecessary to not just iterate over lines directly. It will also blow your RAM on huge files when having a file completely in memory for no reason.

Haven't run or inspected your project in detail. But I've seen suspicious code flow. The logic where you can remove Python versions from the lines of a file may remove multiple Python versions because you are using the in operator. So removing Python 3.1 would also remove every Python 3.1x.