5 ms·

Photos: In folders named "YYYY/MM.N Descriptive event title" like "2019/05.1 Birdwalk with Stephanie". This really helps me find things later. Technical librar

Photos: In folders named "YYYY/MM.N Descriptive event title" like "2019/05.1 Birdwalk with Stephanie". This really helps me find things later. Technical library: Academic Topic/subtopic/ then pdf title Music: I use beets now, which imports and organizes everything Household: Accounts folder, Mortgage folder, Appliances folder with subfolders for each appliance containing manuals, photos, and maintenance info. Systems folder: subfolders for various IT systems and lots of related data in them Projects folder: topic/project name mostly, sometimes with subtopics Documents: YYYY/topic for things that I can find by year later, like taxes, licenses. Also used as longterm archive for projects. Software/repo for various repos that don't fit in other categories (not too happy with this) /opt/venvs for lots of python virtual environments. Pretty much everything is in a mirrored ZFS pool with auto-snapshots (for rewinding in the event of accidental deletions) and occasionally dumped to external drives put in fireproof/floodproof safe (and taken offsite).

silviogutierrez 6y ago
Are your venvs themselves the git repo too? Sounds like they're not, because you have a different project folder. What's your rationale for now putting the venv inside the project and ignoring it? À la node_modules. I've shifted to this after years of your method and like it. I do hate .gitignore expanding arbitrarily. But that's life.
- chrisshroba 6y ago
  (not op) One minor reason I'm considering stopping putting virtual envs inside the project is that not all tools I use support ignore files, and it's one extra thing to remember to ignore in each individual project. Putting venv/ in my .gitignore is one thing, but making sure grep, ag, tree, fzf, etc. all ignore it is an additional step. Granted, I believe some of those tools do respect .gitignore. I just don't see a benefit to having the virtualenv inside the project directory.
- acidburnNSA 6y ago
  They are not. The main reason is that I often use a venv in a few projects. This is just laziness really, and I don't think it's any better than what you're recommending.
- 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 ago
    Late 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...
sneak 6y ago
Recommend MM.0N, or better yet, YYYY/YYYY-MM-NN. Zero padding months means they will sort properly, and not jan oct nov dec feb Putting the year in the sub folder means they can be moved around/back/out (or zipped) without losing important metadata.
- christiangenco 6y ago
  YYYY-MM-NN, or ISO-8601, is objectively the best date format[1]. 1. https://xkcd.com/1179/ https://xkcd.com/1179/
RMPR 6y ago
>Photos: In folders named "YYYY/MM.N Descriptive event title" like "2019/05.1 Birdwalk with Stephanie". This really helps me find things later. To find things later I use the tags feature of Shotwell

silviogutierrez 6y ago

Are your venvs themselves the git repo too? Sounds like they're not, because you have a different project folder. What's your rationale for now putting the venv inside the project and ignoring it? À la node_modules. I've shifted to this after years of your method and like it. I do hate .gitignore expanding arbitrarily. But that's life.

chrisshroba 6y ago
(not op) One minor reason I'm considering stopping putting virtual envs inside the project is that not all tools I use support ignore files, and it's one extra thing to remember to ignore in each individual project. Putting venv/ in my .gitignore is one thing, but making sure grep, ag, tree, fzf, etc. all ignore it is an additional step. Granted, I believe some of those tools do respect .gitignore. I just don't see a benefit to having the virtualenv inside the project directory.
acidburnNSA 6y ago
They are not. The main reason is that I often use a venv in a few projects. This is just laziness really, and I don't think it's any better than what you're recommending.
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 ago
  Late 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...

sneak 6y ago

Recommend MM.0N, or better yet, YYYY/YYYY-MM-NN. Zero padding months means they will sort properly, and not jan oct nov dec feb Putting the year in the sub folder means they can be moved around/back/out (or zipped) without losing important metadata.

christiangenco 6y ago
YYYY-MM-NN, or ISO-8601, is objectively the best date format[1]. 1. https://xkcd.com/1179/ https://xkcd.com/1179/

RMPR 6y ago

>Photos: In folders named "YYYY/MM.N Descriptive event title" like "2019/05.1 Birdwalk with Stephanie". This really helps me find things later. To find things later I use the tags feature of Shotwell