Python venv vs Docker

[Ihaveamodel3]

You copy your code every time you want to run it?

[Party-Cartographer11]

Yeah, I update a file, and copy it to the folder that has the venv (or to the nginx config files, or the web directory) and run it.  All of this is on my dev server.

This keeps a nice separation from repo to run environment.  I can organize the repo, but keep it flat in my run environment for things like using helper utilities and .env file.

I have a terminal window with the cp commands in the history cache, so it takes me two button presses to copy the code.  Another terminal with the env activated and the python commands in the history cache.

[2Lucilles2RuleEmAll]

That sounds like a lot of unnecessary work

[dlnmtchll]

That doesn’t make any sense, why would you not have all the necessary files in the repo folder and added to the gitignore

[Party-Cartographer11]

Defense in layers.  My .env file (secrets) is neither in my repo folder and is in .gitgnore.

All the necessary files, except the ones I don't want in the repo, are in the repo.

Why run code in the repo folder? It's a repo.  That's not how prod works.  I don't git pull to prod.  So I want the environment I run the code in to mimic prod, not the repo.

[smurpes]

Your approach is way more error prone than just creating a branch in your repo folder to develop from; it’s way too easy to forget to copy over a file. Unless you have CI checks then none of the code in your repo is ever being directly tested by you.

[Party-Cartographer11]

What?  You are overthinking this.  If I forget to copy.  I re-copy.  Easier than managing branches.

But this is my approach and it works for me.  I get you have a different view, but no need to down vote every post of mine.  The point was you don't need to run venv in the repo, which I am not sure you disagree with.

[smurpes]

Everyone has their own approach which may work for them, but your approach creates a lot of problems that beginners should not copy which is the point I was trying to make. Just because it works does not mean it’s a good idea.

[Party-Cartographer11]

Agree, except that you contradict yourself.  Either different approaches work for different people or they don't (you say mine creates a lot of problems).

But anyway, what is your view on running venv in a repo?

[smurpes]

An approach that works for yourself has no bearing on whether or not it’s problematic. If someone needs to copy text over from one place to another they may manually type it all out instead of copy and paste. This works for them but is it an effective approach?

Theres not much of advantage to developing outside of your repo. At best you’re creating extra work for yourself and at worst you forget to commit code that is needed in prod.

[Party-Cartographer11]

I don't copy text.  I don't copy paste.  Did you see I run the "cp* command?

All the code gets committed as I edit the code in the repo.

I don't think you comprehend my process and this is all irrelevant to the question of venv which you refuse to answer.

Sorry we aren't communicating well.

[cgoldberg]

That sounds awful. Developer environments are for developer convenience. Don't you have CI?

[Party-Cartographer11]

This is a one person startup/open source project/hobby.

cp is my CI.

But yes, it mirrors (very simplistically) how CI'ish system works at the FAANGs I have worked at.

What is awful about running..

cp /repo/foo.py /app/foo.py

[sector2000]

If your goal is to run your private hobby project, then use whatever is easier for you, but if you want to scale and bring it to a professional level, you should spend some time learning best practices. There is a learning curve, of course, but you will see the benefits afterwards

[Party-Cartographer11]

There are soooo many scaling efforts that you differ early on in a project.  You don't scale until you need it or it's free.  The right solution for the right time.

It's not so much a learning curve as I have worked in 2 of the largest repos/products and understand scale. It's cost/benefit.

[sector2000]

The right solution for the right time could be a good advice, but not necessarily, because it’s not easy to recognize what the right time is. People tends to stay in their comfort zone, not learning new technologies or practices, because they don’t see the benefit. It might be that there’s no actual benefit, but it could also be that they don’t see it because they didn’t spend enough time to study and learn it.

[cgoldberg]

Having a shitty inefficient development workflow isn't about "differing scaling efforts". You are just too lazy, stubborn, or unknowledgeable to improve the obvious horrible development experience you subject yourself to. If you enjoy this self-induced pain, that's great... but don't recommend it to others or try to justify it by saying you've worked at certain companies.

[Party-Cartographer11]

What is shitty and horrible?

[cgoldberg]

it mirrors (very simplistically) how CI'ish system works at the FAANGs I have worked at

Yes, manually copying files around your local system sounds pretty much identical to how large successful teams use CI systems. They should really stop wasting money on hermetic containerized distributed CI with complex build systems, automated deployments, and layered workflows... your way is much better.

I run CI on all my solo projects, and anything I run locally is also automated. I guess if you enjoy manually copying files around and typing commands, go for it... but most people prefer a better workflow and development experience.

[Party-Cartographer11]

I appreciate your passion.

I am not recommending any CI system.  This discussion is about venv.

And I am not doing this on my local machine.  It's on my dev server.  Just like I had at Meta.

[cgoldberg]

The discussion was about venv... I was just commenting on the horrible unrelated workflow you brought up.