-
Notifications
You must be signed in to change notification settings - Fork 5
Conversation
Reminder: we need to look into what Ruby versions are supported, because not all have this |
Well, we can bump the major and remove support of old Rubies. As a suggestion, you can change this project to use Github Actions as I proposed here WeTransfer/sqewer#88 |
I'm currently awaiting a response on https://github.com/WeTransfer/image_vise_standalone/issues/300#issuecomment-892649130. |
0d0e55b
to
47c21f4
Compare
- 2.4.4 | ||
- 2.5.1 | ||
- 2.6.2 | ||
sudo: false |
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 has no effect anymore.
ae26e9a
to
3563018
Compare
a786851
to
0275e74
Compare
0275e74
to
ed8bd17
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.
The ks
removal is perfect 😍 but there are a couple of other points we should probably look into
CHANGELOG.md
Outdated
* Add support for Ruby 2.7 and onwards (including Ruby 3.0) | ||
* Drop support for Ruby 2.6 and lower | ||
* Remove `ks` dependency | ||
* Add `addressable` runtime dependency |
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.
Why do we need to depend on Addressable? GIven that this is a library. Are there any features in Addressable we are using which are not provided by uri
from stdlib?
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.
Good question! URI.encode
/URI.escape
and URI.decode/URI.unescape
have been removed in Ruby 3. For Ruby 3 you have to work with URI.encode_www_form
or URI.encode_www_form_component
, which have a different API. I tried those, but it was a hassle to get that working. Also, I could only test it on Travis CI and not locally, making matters more difficult. Keeping the time invested already in mind I went for the pragmatic solution proposed in docusign/docusign-esign-ruby-client#45. More context can be found here https://docs.knapsackpro.com/2020/uri-escape-is-obsolete-percent-encoding-your-query-string. Feel free to have a try, as it should be possible, but I can't really spend more time on this than I have.
image_vise.gemspec
Outdated
@@ -22,25 +22,27 @@ Gem::Specification.new do |spec| | |||
raise "RubyGems 2.0 or newer is required to protect against public gem pushes." | |||
end | |||
|
|||
spec.required_ruby_version = ">= 2.7" |
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.
Is there any reason we need to require 2.7+? Keyword init for structs is available since 2.5 and even a few internal WT apps are still using 2.6+
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.
@fabioperrella suggested to only support the stable releases. Ruby 2.5 is not maintained anymore and the security maintenance for 2.6 will also end soon (https://www.ruby-lang.org/en/downloads/). I'm happy to lower this, but I'll leave that decision up to you and Fabio.
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.
@julik is there a reason to keep compatibility with EOL Ruby versions?
@kodnin I think we need to support >= 2.6
because the end of life will happen only in 7 months -> https://endoflife.date/ruby, wdyt?
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 trying to make it work for Ruby 2.6.
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 works™.
lib/image_vise/pipeline.rb
Outdated
operator_builder = ImageVise.operator_from(method_name) | ||
self << operator_builder.new(*a) | ||
self << operator_builder.new(**args) |
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.
Is the 2.7 keyword argument treatment the reason we need to require 2.7? If so it is unpleasant but there likely is a solution we could try to stay backwards-compatible
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's the keyword argument treatment in Ruby 3 that is the problem (https://www.ruby-lang.org/en/news/2019/12/12/separation-of-positional-and-keyword-arguments-in-ruby-3-0/). Ruby 2.7 builds fine without this change, Ruby 3 doesn't. Do you have a suggestion to make it backwards-compatible?
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.
Just wondering, isn't it backwards compatible already?
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 looks like it is, I think
As I suggested in another discussion, if we add support to Ruby 2.6 as well, Travis will tell us if this works 😄
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.
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.
What about something like this?
def method_missing(method_name, args = {}, &blk)
operator_builder = ImageVise.operator_from(method_name)
# TODO: When we remove support for Ruby 2.6, we can remove this condition
if args == {}
self << operator_builder.new
else
self << operator_builder.new(**args)
end
end
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.
For now I did this 5caf08c. I can try your solution as well.
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.
There you go, fd583fb.
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 is good for me!
Co-authored-by: Fabio Perrella <[email protected]>
97c1ccf
to
5caf08c
Compare
053b755
to
a20fc6d
Compare
a20fc6d
to
fd583fb
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.
nice job!
Cool, then it's up to @julik to decide. Who's going to do a gem release? |
no need to remove backwards-compat just yet
We can test only on "oldest" and "latest", "in-between" might not be required
we will deal with it later, for now it is good enough simply not to require it for using ImageVise
@julik I would like to understand why we still need to support Ruby 2.5 which is already an EOL version |
@fabioperrella Sure! I think removing support for something on a library that people use is a balance between effort to keep supporting it and the use of the library by others. Even though a version of Ruby is EOL, as long as we can cheaply test against it (and it doesn't require too many workarounds) when we are providing a library we should keep support for older versions as long as is practical. I use image_vise in a few of my own apps, and I don' remember which ones of them are still on 2.5 - just an example. So I try to look at it from the perspective of a user: if we drop support for a runtime version, we cause them inconvenience. Some would not be able to update image_vise due to this requirement because their app might be using something that can't run on 2.6+. So: the line of thought that I have here is that if it is not a large effort to maintain compatibility with older versions of Ruby we, as library authors, absolutely should maintain it. |
ok got it, thank you for the explanation! |
Remove
ks
gem as it breaks Ruby 3 compatibility.image_vise
is (still) used in https://github.com/WeTransfer/spaceship.