Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardize Development Environment #6

Closed
VincentLa14 opened this issue Jan 2, 2019 · 2 comments
Closed

Standardize Development Environment #6

VincentLa14 opened this issue Jan 2, 2019 · 2 comments

Comments

@VincentLa14
Copy link
Member

In other Data Science Working Group projects, I've used Anaconda to manage Python Environments. I'm open to continue doing this or other solutions (e.g. Docker image), but we should have some way to standardize Development Environment to facilitate onboarding.

Very basic MVP could even just be a list of steps to do manually. We should then document this in our Onboarding Docs. My proposal would be to create a folder called "onboarding" within the root directory with different Markdown pages within that directory.

For example, the Data Science Working Group Small Business Administration Project had this: https://github.com/sfbrigade/datasci-sba/tree/master/onboarding

@frhino
Copy link
Collaborator

frhino commented Jan 11, 2019

Nick would you mind writing up a small blurb on the Readme for how to work with the requirements file? Lots of people getting started with python wind up with python downloaded from pthon.org as well as anaconda environments and maybe some other flavor. It would be cool if we could say, "if you have installed python from download at python.org, do this. But if you have python installed via Anaconda, do that."

@frhino
Copy link
Collaborator

frhino commented Jan 11, 2019

Vincent that collection of onboarding docs you linked to is amazing. OpenTransit will definitely be wholesale stealing that. I think you, Nick, and Daniel should all sign off on whatever environment management approach you think is the most usable, intuitive, common, etc. I can be the litmus test on whether it's adequately documented for let's say "less technical" people.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

4 participants