Open Stack

On 2016-08-16 17:38:32 -0500 (-0500), Brant Knudson wrote:
> Is bindep.txt meant to be used by anything other than OpenStack
> CI? (As in, are packagers going to rely on it?)

It's meant first and foremost to be used as documentation for
developers but formatted in a machine-parseable way so that we can
also rely on it in our CI. I see it less as something to inform
distro packager maintainers, and more something to be informed *by*
them.

> In keystone's bindep.txt, we have packages listed like:
> 
> libldap2-dev [platform:dpkg]
> 
> -> Which is only needed if you install with keystone[ldap] (see
> keystone's setup.cfg[1]).

More that it's needed if you want to run keystone unit tests.

> libsqlite3-dev [platform:dpkg]
> 
> 
> -> Which is only needed for unit tests.

Correct.

> .. and maybe others that aren't needed in all deployments.
> 
> So there's a use case for a) integrating with extras, and b) a
> "test-bindep.txt".
> 
> Maybe this is supported already or is known work to do, or maybe somebody's
> looking for something to work on.
[...]

Our CI looks for platform-relevant package names from bindep both
with a default (empty) profile, and connected with a profile named
"test". Projects can choose to either not bother with test-specific
profiles and treat the bindep.txt list as only being relevant to
test environment setup, or can annotate testing-specific distro
package dependencies with the "test" profile and leave the default
profile to indicate run-time dependencies.

http://docs.openstack.org/infra/bindep/readme.html#profiles
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/install-distro-packages.sh

Keep in mind the primary reason bindep was originally created was so
that our developers didn't have to dig through random and
inconsistent documentation to figure out how to set up a development
environment so they could locally run tests for various OpenStack
projects when trying to do cross-project work. Something as simple
as installing bindep from their distro and then running it with
their CWD in a Git checkout, or perhaps even doing `tox -e bindep`,
ought to be sufficient to let them know what packages they're
missing before they can, e.g., do a `tox -e py35`.
-- 
Jeremy Stanley