Should we really include peepin? about sugardough

[glogiotatidis]

I included peepin because I believe it's a useful tool for development. Most -if not all- sugardough based projects will include more packages in requirements.txt so they will need peepin at some point. That being said we should include documentation on how to use peepin to update requirements. I agree that using peepin is a personal choice but I see sugardough as promoting best practices and peep with peepin is one of them. If one doesn't like it they can remove the line and don't use it (same with peep).

So why include it in requirements.txt and not have a separate requirements-dev.txt? In masterfirefoxos project (based on sugardough) we build a Docker development workflow in which we decided to build a docker image and then run tests against that image and if they pass we deploy that very same image. This way we eliminate the difference between the development environment and production. Long story short: In masterfirefoxos we will install both dev only packages and prod packages so we are OK with one requirements file.

If that's not useful generally and people prefer to have two requirements (requirements.txt and requirements-dev.txt) we can go this way. We would move other packages too to the new file, e.g. flake8

[peterbe]

Thanks for that update. I really appreciate it.

I'm still a noob on all things Docker so I bet I don't understand the needs there as well as others do.

Perhaps one way to satisfy this discussion is to consider using -r to include other requirements files.

For example, for runtime you might only need requirements.txt and for travis and Docker you need to install mock, coverage, nose, peep, peepin etc. so you list those in requirements-all.txt which looks something like this:

-r requirements.txt  # the base system
# sha256: owdsfhsodifjsdpof
mock==1.2.3
# sha256: w0oirjvw0oivjh
peep==2.3.4