Add Requirements component for AppEnv

[sweh]

Hello everybody,

with this PullRequest I'd like to introduce you to a component that I use in conjunction with AppEnv in two larger projects. It is used to store a requirements.lock tailored to the current environment for AppEnv.

You can e.g. hand over a list of development packages that will be installed in editable mode. You can also specify your own download server or Pypi. There is also "global version pinnings" that may be needed in larger projects with multiple AppEnvs.

I would be happy if we could discuss the idea here and maybe come up with a solution that fits into the core of batou.

Stay healthy,
Sebastian

[SoerenWeber]

I use Sebastian's components in another project as well and I'm quite happy with it. It provides a very simple way to setup a virtualenv that contains only a specified set of dependencies and offers some nice features to manage them. In my case, a small and mostly straight-forward deployment, this was the perfect fit.

Some thoughts that may serve as a discussion catalyst:

• At the moment, the requirements.lock file is generated automatically and without intervention. I think it might be better to generate this file manually and keep it in source control, as to provide everyone with a well-specified environment. I'm not sure how to accomplish this elegantly, though.
• I'd like to have a strict mode of the Requirements component that fails if any package doesn't have a pinned version.
• While AppEnv and the component AppEnv do very similar things, it might be confusing that they are named the same.

[ctheune]

Yeah, I have a similar feeling. Generating the lock file this way just doesn't feel natural to me - for the same reasons you're giving.

I'm inclined to reject this PR and open up a ticket where we can discuss things further.

About the other points:

• I have a 'strict' mode in the separate appenv project which works this way: install the environment, and then verify that all the installed packages are exactly the specified ones. This breaks if you don't pin things. (basically: calls pip freeze and compares that to the lock file)

• The naming is an "intended happy mistake". We ended up with somewhat separate implementations of the same basic concept. The appenv in batou is now something that emulates/shadows a normal virtualenv, whereas the other one shadows a complete application. I'm open for renaming suggestions, I'm leaning towards renaming the thing that lives in batou.