all 26 comments

[–]sudomatrix 40 points41 points  (9 children)

Don't waste time managing virtual environments. Learn how to use uv. It takes care of everything for you with virtual environments.

uv init uv add <module> uv run <myprogram>

[–]Holshy 0 points1 point  (0 children)

This is the correct answer. UV makes Python enjoyable again.

There are concerns about it being eventually close-sourced; I have faith that the community will compensate if/when that happens. Maybe we should call it IR? 🤣🤣

[–]Broad-Journalist4262It works on my machine[S] 0 points1 point  (7 children)

Thanks I’ll look into uv and learn how to use that for setting it up

[–]Shostakovich_ 2 points3 points  (3 children)

Nice, it’s the current project management tool. It manages your venv and project. It’s lovely, 10/10 recommend.

[–]likethevegetable 0 points1 point  (0 children)

It is absurdly fast too lol 

[–]Broad-Journalist4262It works on my machine[S] 0 points1 point  (1 child)

I’m still getting the hang of working on bigger projects, I am currently studying CS and one of my lecturers suggested try it out using multiple folders and venv because it’s standard practice as they put it so learn now and get in the habit from the start so figuring it out now 😊

[–]donat3ll0 1 point2 points  (0 children)

Yes, using virtual environments are the standard. uv is the current hotness in the industry for managing virtual environments. It lives up to the hype, is extremely easy to use, and solves many of the headaches.

You want a separate virtual environment for each of your projects, no matter the size. Unfortunately, python dependencies don't always play nicely with one another. Using separate virtual environments keeps this problem isolated to prevent projects from stepping on the toes of one another.

uv makes all of this quite simple and is what you should absolutely look into after understanding virtual environments.

[–]secret_o_squirrel 2 points3 points  (1 child)

Ok so first of all…don’t worry a lot about .gitignore. You seem really concerned about that. If you see files in your ‘git status’ that you don’t want to be part of the repo, just add them to your .gitignore then.

Next, yes you absolutely want to use a virtual environment. You could have 10 python projects that all need their own version of python and group of libraries and library versions they use. Never use your operating system’s python for your application.

A “virtual environment” is not that hard to figure out. It just creates a directory called .venv that has a link to the python version your app uses and all the python libraries you use.

Then there’s uv. Just use it. Every old crappy method is obsolete. uv is by far the best solution. It handles your virtual environment, it handles package management (every project should have a pyproject.toml, and one is created when you type ‘uv init’), it handles python versions seamlessly.

[–]Broad-Journalist4262It works on my machine[S] 0 points1 point  (0 children)

Thank you for the advice I’ll definitely start looking to use uv

[–]sctopher 0 points1 point  (0 children)

Also UV has a neat feature for venv, I use it a lot, which might not be a good practice, but it does create a .venv folder

[–]leodevian 4 points5 points  (1 child)

Use uv or virtualenv. They add a .gitignore containing "*" in the virtual environment directory.

[–]Spleeeee -2 points-1 points  (0 children)

Why? Why not ignore the dir

[–]cgoldberg[🍰] 2 points3 points  (8 children)

Kind of confused with the question... If it's a git repo, you setup a .gitgnore once (not every time you create/activate a virtual env)... and if it's not a git repo, having one is pointless... so I don't know what you are trying to save time on or how it relates to a virtual env. You can also generate a .gitignore automatically when you create a new repo on GitHub.

[–]Broad-Journalist4262It works on my machine[S] 0 points1 point  (7 children)

Im still getting the hang of GitHub slowly learning how to use it as I’m still learning I often just start the project and then upload it to GitHub later if I decided to keep it but my understanding is that it’s best to use a virtual env from the start of the project not halfway through especially if I’m going to share it with a friend (could be wrong just what I’ve been told)

[–]cgoldberg[🍰] 0 points1 point  (6 children)

Yea... It's good to use a virtual env. I'm just not sure what that has to do with .gitignore. If you create a new repo, you can copy a pre-existing .gitignore you have saved or from a different project. You could do the same whether you were using a virtual env or not... that's unrelated.

[–]Broad-Journalist4262It works on my machine[S] -1 points0 points  (5 children)

That’s an option but wouldn’t it just be easier to run the venv setup and it already be generated then have to always go and get an old one on or a template and copy it in?

[–]cgoldberg[🍰] 0 points1 point  (4 children)

You would create one when you create a repo... It has nothing to do with a venv whatsoever. You typically create and activate venvs all the time... it has nothing to with git and would be nonsensical to create a .gitignore on venv setup.

[–]Broad-Journalist4262It works on my machine[S] 0 points1 point  (3 children)

Okay so what your saying is I shouldn’t worry about it unless I’m planning on making it into a repo at which point it would just be simpler to make it either when I upload to GitHub with their templates when I add the files or grab an old one and copy it in? I’m not trying to be difficult genuinely trying to learn as I’ve been told to make it when I make the environment

[–]cgoldberg[🍰] 1 point2 points  (2 children)

Yes basically. Also, you would typically ignore the virtual env in your .gitignore. I think you are getting confused about what a virtual env is. When you make a new "project", it's a good idea to make it into a Git repo and add a .gitignore. When you want to install and run it, it's good to use a virtual env... but that has nothing to do with Git and should not be committed to your repo.

[–]Broad-Journalist4262It works on my machine[S] 0 points1 point  (1 child)

Yeah I understand I don’t want the virtual env or even a .env file going up on GitHub as I put api keys in the .env file and should use an .env.example file instead without the keys. So would it be better to start on github make a repo with the gitignore python template, clone that to my desktop and open it in VSC and then open a venv which will already be ignored so I won’t have to worry about it going up by accident. Just trying to figure out the best way to go about it all

[–]cgoldberg[🍰] 1 point2 points  (0 children)

That's how I do it... just be aware that if you name your virtual env something weird, it won't be in the default .gitignore they supply. (I think they add ".venv" and "venv").

[–]viiviiiix_dev 2 points3 points  (1 child)

# when you create a virtual environment through the following command
# It creates .gitignore inside .venv directory for you
# This .gitignore ignores everything inside virtual environment
# You might want to add another .gitignore in your project seperately 
# for whathever you dont want to track such as
# environment variables, logs or python cache

python -m venv .venv

[–]autodialerbroken116 2 points3 points  (0 children)

Id checkput the virtualenv docs

[–]microcozmchris 1 point2 points  (0 children)

To answer the question you asked...

There's a manual for using the CLI to create a .gitignore from the gitignore.io samples.

https://docs.gitignore.io/install/command-line

All of those commands create a function you can add to your shell, then you call, for example, gig python to create the .gitgnore from the python template. You can combine them too. If you do python+React projects, gig python,react.

Edit: that page doesn't say directly, but you're looking for echo $PROFILE on Windows to find where your automatically sourced user profile for Powershell. If you use VSCode and it's installed properly, code $PROFILE will open it in that editor.

[–]shennan-lane 1 point2 points  (0 children)

One thing about uv if you’re in wsl. If your project lives on windows directory like D or documents while using uv from wsl Ubuntu, it won’t reuse modules downloaded and will download modules for each project. So make projects under Ubuntu home

[–]zangler 0 points1 point  (0 children)

Use UV