There is Nix integration in direnv so I have use nix there and it works. And yes, it calls nix each time I enter project directory, it is noticeable, but it is once per launch, so it isn’t much of the problem.
Erm… I didn’t read the entire article, but all I do is createdb (and createuser) for each project. Is there anything wrong or worse with this approach vs. what is described in the OP?
Nothing wrong. This however is worthwhile because it makes it easier to kick-start people not used to Postgres. I recall an episode of @garbage.fm where our own @jcs when asked why lobste.rs was using MySQL said something to the like that this was the database he was already used to and he never remembered how to quickly setup Postgres DB access for the app for local development while MySQL just worked out of the box.
Not at all, same that I do. If one of the main issues is getting new developers up and running I’ve found https://postgresapp.com/ super useful as you can have multiple postgres versions running and it handles updates and all that for you. It’s mac only though but I don’t think it would be too hard to make something similar for mac and windows as well.
One of the first things I do in a db-backed project as well is setup db migration and db instantiation code so that I can get projects up and running with minimal fuss moving forward. It’s too easy to get into a kludge of SQL and other scripts peppered all over and lost one-off statements modifying your database schema/data while you’re in early/heavy development. Getting db migration stuff working right away means new developers on the project don’t have to worry about that stuff too much if it isn’t in their domain.
The difference is that your approach changes the global state of the system. Including for example having a daemon running and potentially listening on the network, as mentioned in the article.
With the article’s approach, you don’t have to worry about name collisions between the database names, or with leaving behind junk in the system program after getting rid of a project.
Very nice. I’ve been half-way there by hand, but automating using
direnvlooks promising.Would this call
nixevery time you enter the project directory? Isn’t that noticeably slow?There is Nix integration in
direnvso I haveuse nixthere and it works. And yes, it callsnixeach time I enter project directory, it is noticeable, but it is once per launch, so it isn’t much of the problem.This is great – thanks! Gives me lots of ideas!
Erm… I didn’t read the entire article, but all I do is
createdb(andcreateuser) for each project. Is there anything wrong or worse with this approach vs. what is described in the OP?Nothing wrong. This however is worthwhile because it makes it easier to kick-start people not used to Postgres. I recall an episode of @garbage.fm where our own @jcs when asked why lobste.rs was using MySQL said something to the like that this was the database he was already used to and he never remembered how to quickly setup Postgres DB access for the app for local development while MySQL just worked out of the box.
Not at all, same that I do. If one of the main issues is getting new developers up and running I’ve found https://postgresapp.com/ super useful as you can have multiple postgres versions running and it handles updates and all that for you. It’s mac only though but I don’t think it would be too hard to make something similar for mac and windows as well.
One of the first things I do in a db-backed project as well is setup db migration and db instantiation code so that I can get projects up and running with minimal fuss moving forward. It’s too easy to get into a kludge of SQL and other scripts peppered all over and lost one-off statements modifying your database schema/data while you’re in early/heavy development. Getting db migration stuff working right away means new developers on the project don’t have to worry about that stuff too much if it isn’t in their domain.
The difference is that your approach changes the global state of the system. Including for example having a daemon running and potentially listening on the network, as mentioned in the article.
With the article’s approach, you don’t have to worry about name collisions between the database names, or with leaving behind junk in the system program after getting rid of a project.