Skip to content
This repository has been archived by the owner on Jan 8, 2024. It is now read-only.

Remove ks dependency #46

Merged
merged 25 commits into from
Aug 17, 2021
Merged

Remove ks dependency #46

merged 25 commits into from
Aug 17, 2021

Conversation

kodnin
Copy link
Contributor

@kodnin kodnin commented Jul 29, 2021

Remove ks gem as it breaks Ruby 3 compatibility. image_vise is (still) used in https://github.com/WeTransfer/spaceship.

@kodnin kodnin marked this pull request as ready for review July 29, 2021 11:48
@kodnin
Copy link
Contributor Author

kodnin commented Jul 30, 2021

Reminder: we need to look into what Ruby versions are supported, because not all have this Struct option yet. That was the whole point of the ks gem.

@fabioperrella
Copy link
Contributor

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

@kodnin
Copy link
Contributor Author

kodnin commented Aug 4, 2021

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.

@kodnin kodnin force-pushed the remove-ks-dependency branch from 0d0e55b to 47c21f4 Compare August 10, 2021 12:49
- 2.4.4
- 2.5.1
- 2.6.2
sudo: false
Copy link
Contributor Author

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.

@kodnin kodnin force-pushed the remove-ks-dependency branch from ae26e9a to 3563018 Compare August 10, 2021 13:08
@kodnin kodnin force-pushed the remove-ks-dependency branch 2 times, most recently from a786851 to 0275e74 Compare August 10, 2021 15:08
@kodnin kodnin force-pushed the remove-ks-dependency branch from 0275e74 to ed8bd17 Compare August 10, 2021 15:13
@julik julik self-requested a review August 10, 2021 15:26
Copy link
Contributor

@julik julik left a 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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@@ -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"
Copy link
Contributor

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+

Copy link
Contributor Author

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.

Copy link
Contributor

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?

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'm trying to make it work for Ruby 2.6.

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 works™.

operator_builder = ImageVise.operator_from(method_name)
self << operator_builder.new(*a)
self << operator_builder.new(**args)
Copy link
Contributor

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

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'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?

Copy link
Contributor Author

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?

Copy link
Contributor

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 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There you go, fd583fb.

Copy link
Contributor

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!

image_vise.gemspec Outdated Show resolved Hide resolved
@kodnin kodnin force-pushed the remove-ks-dependency branch from 97c1ccf to 5caf08c Compare August 11, 2021 11:31
lib/image_vise/pipeline.rb Outdated Show resolved Hide resolved
@kodnin kodnin force-pushed the remove-ks-dependency branch 2 times, most recently from 053b755 to a20fc6d Compare August 11, 2021 11:47
@kodnin kodnin force-pushed the remove-ks-dependency branch from a20fc6d to fd583fb Compare August 11, 2021 11:56
Copy link
Contributor

@fabioperrella fabioperrella left a comment

Choose a reason for hiding this comment

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

nice job!

@kodnin
Copy link
Contributor Author

kodnin commented Aug 11, 2021

nice job!

Cool, then it's up to @julik to decide. Who's going to do a gem release?

julik added 9 commits August 14, 2021 00:19
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 julik merged commit 83829e7 into master Aug 17, 2021
@fabioperrella
Copy link
Contributor

@julik I would like to understand why we still need to support Ruby 2.5 which is already an EOL version

@julik
Copy link
Contributor

julik commented Aug 17, 2021

@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.

@fabioperrella
Copy link
Contributor

ok got it, thank you for the explanation!

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

Successfully merging this pull request may close these issues.

3 participants