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

Add prototype of inspec.lock #949

Merged
merged 5 commits into from
Aug 23, 2016
Merged

Add prototype of inspec.lock #949

merged 5 commits into from
Aug 23, 2016

Conversation

stevendanna
Copy link
Contributor

This adds a basic prototype of inspec.lock. When the lockfile exists on
disk, the dependencies tree is constructed using the information in the
lock file rather than using the resolver.

Signed-off-by: Steven Danna steve@chef.io

@stevendanna stevendanna changed the title Add prototype of inspec.lock WIP: Add prototype of inspec.lock Aug 22, 2016
@arlimus arlimus self-assigned this Aug 22, 2016
end
end

def generate_lockfile(vendor_path = nil)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment: Make this an in-memory operation that doesn't render the lock file to disk.

@ksubrama
Copy link

So far so good. This makes sense as the "in progress" code that you walked me through this afternoon. I'm sure a lot of it will be refactored/rewritten soon - hence why most of my comments have a "Comment:" tag in them to denote that I'd simply like you to write a comment to that effect in there in case we don't get around to fixing that bit (you can never be too paranoid). I am 👍 on this.

if parent
parent.url
else
'file://target'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be "file://#{target}"?

@chris-rock
Copy link
Contributor

chris-rock commented Aug 23, 2016

I think the inspec.lock is not generated in the right path. It should be generated within the root profile directory

$ b inspec vendor test/unit/mock/profiles/dependencies/inheritance 
$ cat test/unit/mock/profiles/dependencies/inheritance/inspec.lock
cat: test/unit/mock/profiles/dependencies/inheritance/inspec.lock: No such file or directory
$ cat inspec.lock 
---
lockfile_version: 0
depends: []

desc 'vendor', 'Download all dependencies and generate a lockfile'
def vendor(path = nil)
profile = Inspec::Profile.for_target('./', opts)
lockfile = profile.generate_lockfile(path)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 that this is part of the profile

Copy link
Contributor

@chris-rock chris-rock Aug 23, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe should call that profile.dependencies. The lockfile is only a written form of all the dependencies. The word lockfile is confusing on top of profile, because a profile should only know about dependencies but not lockfiles. I would attache the lockfile to DependencySet, instead of the call I would give it a path where the expected lock file should be located

This adds a basic prototype of inspec.lock. When the lockfile exists on
disk, the dependencies tree is constructed using the information in the
lock file rather than using the resolver.

Signed-off-by: Steven Danna <steve@chef.io>
Signed-off-by: Steven Danna <steve@chef.io>
Eventually I think we'll want this as part of the fetcher API generally.

Signed-off-by: Steven Danna <steve@chef.io>
Signed-off-by: Steven Danna <steve@chef.io>
@@ -211,6 +212,44 @@ def locked_dependencies
@locked_dependencies ||= load_dependencies
end

def lockfile_exists?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should hand the whole lockfile methods into the Lockfile class and just call it from there. Resolved lockfiles result in Dependencies. I think a profile should not know about lockfiles, only dependencies

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree we need to increase the separation between Lockfile and Profile. @ksubrama and I discussed that a bit and I think the work to change how profile loading works will drive some of that out. However, in terms of the lockfile_exists? method specifically, I'm not sure it is true that we don't want profile knowing about lockfiles at all since the lockfile now lives in the profile directory.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not fan of introducing side-effect to classes that should work independently. We should at least bundle that into the dependency implementation instead of the profile implementation

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It really isn't clear to me how lockfile_exists?() is a side-effect? Whether a lockfile is inside the profile is a property of the profile and depends on information (the path to the profile) that you don't necessarily want to expose to users of the class.

@stevendanna
Copy link
Contributor Author

I think the inspec.lock is not generated in the right path. It should be generated within the root profile directory

See my comment in-line re this. Currently vendor assumes you are in a profile.


def self.from_file(path)
parsed_content = YAML.load(File.read(path))
version = parsed_content['lockfile_version']
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool to have that built in from the very beginning 👍

@chris-rock
Copy link
Contributor

Thanks @stevendanna this works:

$ cd test/unit/mock/profiles/dependencies/inheritance
$ inspec vendor 
$ cat inspec.lock 
---
lockfile_version: 0
depends:
- name: profile_a
  resolved_source: file://../profile_a
  version_constraints: ">= 0"
  dependencies:
  - name: profile_c
    resolved_source: file://../profile_c
    version_constraints: ">= 0"
- name: profile_b
  resolved_source: file://../profile_b
  version_constraints: ">= 0"
- name: os-hardening
  resolved_source: https://github.com/dev-sec/tests-os-hardening/archive/master.tar.gz
  version_constraints: ">= 0"
  content_hash: d6c5299a7cdcce2040c157cc81cb2b21a85d3001493f8f3fb2aba175b9aa046c

@chris-rock
Copy link
Contributor

discussed with @stevendanna, we are going to address my comments in later PRs

@chris-rock chris-rock merged commit 961e815 into master Aug 23, 2016
@chris-rock chris-rock deleted the ssd/deps-lockfile branch August 23, 2016 13:25
@stevendanna
Copy link
Contributor Author

@chris-rock And I had an in-person discussions where we agreed that:

  • The high-level coordination of Inspec::Profile, Inspec::Lockfile, and Inspec::DependencySet isn't right yet. We think that the right path here will get clearer as we work on scoping profile loading.
  • The UX around the vendor command needs to be finalized. The path argument should probably be the path to the profile and then the lockfile should get placed at the same level as inspec.yml. The vendor directory can move to an option.

@chris-rock chris-rock modified the milestone: 0.32.0 Aug 24, 2016
@chris-rock
Copy link
Contributor

related to #888

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

Successfully merging this pull request may close these issues.

None yet

5 participants