3 ms·
I also put virtualenvs in a single centralized location (~/.virtualenvs), and manage their contents via Poetry. The main reason is that I sync my Git projects
by jabirali 6y ago
I also put virtualenvs in a single centralized location (~/.virtualenvs), and manage their contents via Poetry.
The main reason is that I sync my Git projects via Tresorit (“encrypted Dropbox”). This lets me switch computers without committing and pushing code that is not “ready”; makes it easier to sync all projects I work on to my backup server; and lets me copy around project files that I don’t want to commit (e.g. messy WIP and TODO notes).
This doesn’t work well with virtualenvs inside a repo, because (i) the virtualenvs are not portable, and (ii) syncing a virtualenv is slow. Instead, I sync a Poetry lock file, which makes it trivial to recreate the “same” virtualenv on other machines.
- silviogutierrez 6y agoLate reply: I used to do this. These days, I treat my projects like cattle, not pets.[1] Using nix I made everything reproducible. So given a project name and branch name, everything is checked out (shallow checkout for big projects) and setup for me. If I'm working on another machine, just run "launch org/project <branch>" and profit. There are edge cases: if I forget to push, I do remote in and do that. When I'm done with a branch, I make it a habit to purge that "instance" of the project. But first I have git go through the project and its submodules (if any) and ensure everything has been pushed and the repo not modified. Note: my projects are database backed and have state etc. All of that is part of the setup script, per project. If your database is in a customized-state for development for a super specific scenario, then you're probably not automatically testing it and that's a code smell to me. [1] https://medium.com/@Joachim8675309/devops-concepts-pets-vs-cattle-2380b5aab313 https://medium.com/@Joachim8675309/devops-concepts-pets-vs-c...