Comment by acidburnNSA | Hacker News Reader

Comment by acidburnNSA | Hacker News Reader

Parent Full thread

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).

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.

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.

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-c...

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.

(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.

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.

YYYY-MM-NN, or ISO-8601, is objectively the best date format[1].

1. https://xkcd.com/1179/

>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

Reply on news.ycombinator.com