Should do `git pull` in .rbenv and `ruby-build` if they exist already and then this script can be used to update stuff?
I’ll submit a PR if this is a good idea.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [8월 16, 2018, 12:45오전 UTC](https://meta.discourse.org/t/keeping-rails-dev-up-to-date/94832/2 "2018-08-16T00:45:33Z")
I am mixed on adding too much fancy here, getting into the world of installing Ruby on machines is a world of pain. I prefer to double down on docker dev image we have which takes care of all of this and more.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [8월 16, 2018, 1:28오전 UTC](https://meta.discourse.org/t/keeping-rails-dev-up-to-date/94832/3 "2018-08-16T01:28:16Z")
I like the idea of docker Dev, but my experiences with docker dev have been mixed.
How many folks on team are using it for their development work? Are you?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [8월 16, 2018, 1:36오전 UTC](https://meta.discourse.org/t/keeping-rails-dev-up-to-date/94832/4 "2018-08-16T01:36:35Z")
> [@pfaffman](#):
>
> Are you?
No I do not usually use it but I like pain, I am not really the demographic for an “easy dev install” setup.
---
### Author:  [@LeoMcA](https://meta.discourse.org/u/LeoMcA)
#### Post date: [8월 16, 2018, 1:35오후 UTC](https://meta.discourse.org/t/keeping-rails-dev-up-to-date/94832/5 "2018-08-16T13:35:56Z")
Not on the team, but I use it near daily for all my Discourse core/plugin development work.
I rolled my own scripts to help with my particular workflow (which requires pretty regular switching between a vanilla discourse instance, and one with all the bells, whistles and API keys we hang off Discourse within Mozilla):
> [@Dev environments scripts](https://meta.discourse.org/t/dev-environments-scripts/66319):
>
> I’ve been using the [docker scripts bundled with discourse](https://github.com/discourse/discourse/tree/master/bin/docker) for a while, but I’ve found they don’t work particularly well with my want to often switch between different dev instances (for instance, one running tests-passed, one running a branch where I’m developing an awesome new feature, one running a plugin I’m developing, and so on). So, I rolled my own, heavily inspired by the originals: [https://github.com/LeoMcA/discourse-dev-scripts](https://github.com/LeoMcA/discourse-dev-scripts) I’ve been using them for about a week now and they haven…
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [8월 16, 2018, 3:20오후 UTC](https://meta.discourse.org/t/keeping-rails-dev-up-to-date/94832/6 "2018-08-16T15:20:21Z")
> [@sam](#):
>
> No I do not usually use it but I like pain,
I’m pretty sure that’s how we’re the same. (Though I don’t like pain enough to use Windows.) 😉
> [@sam](#):
>
> I am not really the demographic for an “easy dev install” setup.
Me neither. I’m the kind of person who’s likely to for one reason or other, set up or upgrade a new machine several times a year. Often enough that I’d like to have stuff scripted because it’s not often enough that I remember.
For running final imports I’m increasingly running them in a production container, but when I’m developing an import script, having it run on my desktop unencumbered by a layer of abstraction seems preferable. OTOH, it’s not unlikely that I find that habits that I developed 20 years ago are no longer best practices.
Another pain point for me is running one import on one branch while also being able to switch branches and work on another while the first one is running. Sometimes I’ve thought that docker\_dev would help with that. I’ll see about giving it another look, but I think that unless someone on team actively uses `discourse_dev` it’s likely to be difficult to keep it fresh.
Maybe I’ll give it another shot, but I may still submit a PR that updates rbenv and ruby-build in the dev install script.