-
Notifications
You must be signed in to change notification settings - Fork 53
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
Move ImageName class from osbs client to utils of dockerfile parser. #139
base: master
Are you sure you want to change the base?
Move ImageName class from osbs client to utils of dockerfile parser. #139
Conversation
f6502b9
to
6efc24a
Compare
eb46d2a
to
cc33931
Compare
@rcerven : Is it the intention to keep this repo suitable for python 2? Just to be sure, before I'm going to put too much effort in trying to get that work. I'm having quite a bit of trouble wrapping my head around what's going wrong currently. It seems something with stringIO not accepting the result from the to_string() output. But not sure how i would be able to get it to work. |
c49d40d
to
9736cd9
Compare
mmm for now afaik, @MartinBasti ? |
We don't need it for py2 anymore, not sure about other community users :| |
591af13
to
8ccd28d
Compare
@MartinBasti Whelp, i'm stumped: I've got everything up to snuff: Except for the python 2 bit... Disabling the python2 tests is also a possibility. but that kind of feels like the cowards' way out... |
I'm really thinking about bumping major version and drop py2 support, py2 is dead and enterprise distros can use old versions of Dockerfile-parse, I'll check with other maintainers |
@tim-vk we agreed that we will do a major release of dockerfile-parse without py2 support. I'll drop py2 support in separate PR, so for now ignore py2 failures |
return match.group('image', 'name') if match else (None, None) | ||
image = ImageName.parse(match.group('image')) if match else None | ||
name = match.group('name') if match else None | ||
return image, name |
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.
we are breaking BW compatibility here, I'm not sure if we can do this
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.
As far as i'm aware it shouldn't break backwards compatibility:
Old version: Image was a string
New version: Image is the new ImageName class which has a str representation (which is idential to the original string of the previous version).
This should be backwards compatible (the unit tests reflect this: there are only tests added, not changed).
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.
Addition:
Just realized what I typed above is not 100% true: See the explicit str(s) in util.py (line 51).
impact should still be minimal.
Alternative solution would be keeping the old function.
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.
yes, explicit casting to str() is required, that's breaking change
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.
IMO would be safer to add new function and add deprecation warning to this one
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.
Done!
I could not find any examples within the containerbuildsystem project with deprecations so i opted to just add a simple DeprecationWarning. Let me know if an external package or other method is preferred.
24185cf
to
db63b5f
Compare
Signed-off-by: Tim van Katwijk <[email protected]>
0892b5e
to
eda9de3
Compare
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.
move to 2 commits & finishing touches.
@@ -17,3 +17,7 @@ jobs: | |||
targets: | |||
- fedora-all | |||
- epel-8-x86_64 | |||
|
|||
srpm_build_deps: |
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.
This was apparently still missing in the master repo: I'm not 100% certain if this is correct. Please verify.
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'm still not sure what this fix is fixing, we had not such issue previously
Signed-off-by: Tim van Katwijk <[email protected]>
b794489
to
151f6cd
Compare
Signed-off-by: Tim van Katwijk <[email protected]>
151f6cd
to
5fe6ebb
Compare
dockerfile_parse/parser.py
Outdated
:param from_value: string like "image:tag" or "image:tag AS name" | ||
:return: tuple of the image and stage name, e.g. ("image:tag", None) | ||
""" | ||
DeprecationWarning("Use image_name_from instead.") |
Check failure
Code scanning / CodeQL
Unused exception object
ff6e964
to
6b579f2
Compare
Signed-off-by: Tim van Katwijk <[email protected]>
6b579f2
to
4c76644
Compare
LGMT, very nice :) |
can't you avoid making those breaking changes? (osbs-client and atomic-reactor are using that) and I'd prefer to keep ImageName 100% backwards compatible
|
While I recognize the wish for backwards compatibility, I do think that this is a great opportunity to genuinly think about "what do we want an imagename to be". And ignore the backwards compatibility bit (especially since the repo's you mention are not forced to use this version of the ImageName class. they can still use the old one. Though I hope someone will deprecate that one so everyone can switch to the new one with time). So first: If there is nothing. What would you rather have: an empty string? or None. I would argue that None was a great choice to be returned. This makes checks a lot easier ( Second: a dockerfile does not need to contain a Finally, If we do want to use the argument "backwards compatibility": The imageName class as implemented in this merge request is backwards compatible with existing code. e.g.: So persionally I stand by these changes compared to the imageName class in the osbs-client. They seem to me to be the right way to go. |
Summary of what is discussed in PR #129 :
This PR moves the ImageName class to utils of dockerfile-parse.
I did need to refactor the ImageName class slightly to get the following behavior in-line with dockerfile-parse behavior:
I've refactored & expanded the existing tests to reflect this behavior.
Do keep in mind that these changes are breaking compared to the ImageName class contained in osbs-client.
Maintainers will complete the following section