-
Notifications
You must be signed in to change notification settings - Fork 682
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
Conversation
end | ||
end | ||
|
||
def generate_lockfile(vendor_path = nil) |
There was a problem hiding this comment.
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.
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. |
170f47d
to
d0fc14c
Compare
3e96221
to
b246e11
Compare
b246e11
to
c734c4c
Compare
if parent | ||
parent.url | ||
else | ||
'file://target' |
There was a problem hiding this comment.
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}"?
I think the
|
desc 'vendor', 'Download all dependencies and generate a lockfile' | ||
def vendor(path = nil) | ||
profile = Inspec::Profile.for_target('./', opts) | ||
lockfile = profile.generate_lockfile(path) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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>
c734c4c
to
d9b6210
Compare
@@ -211,6 +212,44 @@ def locked_dependencies | |||
@locked_dependencies ||= load_dependencies | |||
end | |||
|
|||
def lockfile_exists? |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
See my comment in-line re this. Currently |
|
||
def self.from_file(path) | ||
parsed_content = YAML.load(File.read(path)) | ||
version = parsed_content['lockfile_version'] |
There was a problem hiding this comment.
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 👍
Thanks @stevendanna this works:
|
discussed with @stevendanna, we are going to address my comments in later PRs |
@chris-rock And I had an in-person discussions where we agreed that:
|
related to #888 |
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