Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
RFC Dependencies #888
Follow up #798 around dependency resolution.
(1) dependencies are written in
depends: - name: hello [ ... ]
(2) dependencies are based on semantic versioning: http://semver.org/ . Dependencies do not support alpha/pre-release information (9, 10) (see comment)
- version: [op] [version] [...]
(4) each dependency has one source, with the default pointing to
- path: ../relative_path/to/profile - path: /absolute/path - supermarket: owner/name - compliance: owner/name - github: owner/name - url: http://sth...
(5) upon resolution, a lockfile is created in
(6) dependencies are vendored to a local cache in
(7) dependencies provide their library functions the profile (without additional specification). For example: Resources that are defined in libraries are available to the profile that requires it.
(8) dependencies may provide controls via
(9) dependencies are scoped with their name. scoping applies to all aspects, including resources, controls, and attributes. resources are added to the global space if there is no conflict.
... and discuss
The following types are supported:
Profile which is located in a folder on disk. This should only be used for development and debugging.
Does not support version constraints. The folder must exist. If it doesn't, throw an error.
Fixed HTTP/HTTPS-based URL which contains a profile. To retrieve the profile use a HTTP
These sources are translated into a URL upon resolution. All support version indexing. For versions to be indexed, they must be provided via semantic versioning as git tags.
Git is the basic mechanism, which supports an optional branch, tag, commit, or version specification. Version specs are resolved via tags matching semantic versioning patterns. If a version constraint cannot be resolved, an error is thrown.
Github and supermarket build on this source and support all
referenced this issue
Aug 8, 2016
added a commit
Aug 8, 2016
referenced this issue
Aug 8, 2016
As you guys are working on the feature, I would like to know how the default supermarket URL will be resolved? I've seen bugs, where default URL is hardcoded to public supermarket (supermarket.chef.io), which blows up inside firewalled environment where customer has their own supermarket running.
Please consider how/where this URL will be fetched from, and where/how it can be overwritten to point to internal source by default.
In addition to @vinyar the same challenge will happen with our
One solution could be to use the compliance and supermarket url from
To address it, we have 2 options afaics
(A) Is the
(C) I like the idea of defining a source per dependency. But this creates the need to be able to override these locations for environments that don't have direct access to them or have a policy to review and store all dependencies before using. Let's take this for example, where gitlab is a local git repository:
(C1) Passing overriding options to inspec can get wordy very fast and lacks granularity.
(C2) Not wordy for inspec and very granular is to use a file, similar to
(C3) Like (C2) but without another file, but instead using
(D) Should probably design the sources to receive parameters. So, instead of:
have something like this:
same way berkshelf is doing it.
Dom (8) isn't include_controls (all) and require_controls(selective)?
added a commit
Aug 10, 2016
I'm having trouble understanding how some of this dependency RFC will work. It mixes some ideas from dependency systems that do minimal version management and others that do full dependency resolution, usually using a central index of the universe of available packages to speed up the process.
Here is a more basic question that I think we should spell out more explicitly:
Consider: A depends on B and C with no version constraints. B and C depends on D with no version constrains but from different sources. (You can create other examples with completing versions). It seems in this case we have a few options:
Or am I missing an option? Or more generally: For a given dependency "X" are we going to try to find a single version of X to try to load into the app or will we allow for multiple versions.
I'd also like to see us spec out some of the UX of how you will interact with this feature. It seems to me the core operation of a tool like this are:
@arlimus After discussing this with @chris-rock a bit, I think an important point to discuss and make a bit more explicit in this RFC is how dependency will be scoped and the impact that has on the features we need in the dependency resolution.
From our discussion, I believe one of the goals of this work is to allow two different versions of the same dependencies to be loaded at the same time. For example, you might have a dependency tree that looks like:
This proposes that we change inspec such that code inside B can reference code inside D and be sure it is getting the 1.0.0 version of the code, while code inside C can reference code inside D and be sure it is getting the 2.0.0 version of the code. Is this a correct characterization of part of the feature being proposed?
If so, it leads to a follow-on thought:
Is there utility in including the version operators at all. In the dependency management systems I've used (I'm by no means an expert) one of the major reason to include the version operators is because the runtime can only load a single version of a given dependency. Packages use version constraints to ensure that the single version that is loaded is within the range of versions it supports. The package manager solves the constraint problem after getting version constraint information from every source to ensure it has the full universe of dependencies.
However, in the world describe above, it seems that the version constraints would only be used to limit which version is fetched in the absence of a lockfile. However, most of the proposed sources don't have a standard API for exposing information about the available versions.
Which sources do we have that provide version information in an index?
I'll update the spec: