OpenNeo/impress
OpenNeo/impress
1
0
Fork 1
Code Pull requests Activity
impress/Gemfile.lock

541 lines
13 KiB
Text
Raw Normal View History

support concurrent requests. now demands thin and nginx, but hey. it works
2010-10-10 15:46:58 -07:00
GIT
Update gems Ha, I forgot we're including all the vendored gems in the git repo. Maybe that's worth changing? But fine to leave as-is for now.
2023-07-21 18:07:36 -07:00
remote: https://github.com/rubyamf/rocketamf.git
fix null zone ID bug TNT has started serving half-removed Corridor of Chance effects: it has the asset ID and URL and all, but the zone ID is blank. RocketAMF has patched the empty key bug, and now we ignore assets associated with empty keys.
2013-05-23 18:48:19 -07:00
revision: 796f591d002b5cf47df436dbcbd6f2ab00e869ed
move to unstable rocketamf so that it builds hashes from registries, not arrays
2011-01-13 14:22:07 -08:00
specs:
update rocketamf repo
2011-07-31 20:20:04 -07:00
RocketAMF (1.0.0)
move to unstable rocketamf so that it builds hashes from registries, not arrays
2011-01-13 14:22:07 -08:00
upgrade to rails 3, make item tests pass
2010-10-03 16:49:33 -07:00
GEM
Update most URLs to use HTTPS I noticed we didn't have the little lock icon in the browser, and yeah huh there's a lot of `http://` still floating around! Let's fix that!
2023-10-25 15:16:46 -07:00
remote: https://rubygems.org/
upgrade to rails 3, make item tests pass
2010-10-03 16:49:33 -07:00
specs:
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
actioncable (7.2.1)
actionpack (= 7.2.1)
activesupport (= 7.2.1)
Upgrade to Rails 5.2.8.1 Some important little upgrades but mostly straightforward! Note that there's still a known issue where item searches crash, I was hoping that this was a bug in Rails 4.2 that would be fixed on upgading to 5, but nope, oh well! Also uhh I just got a bit silly and didn't actually mean to go all the way to 5.2 in one go, I had meant to start at 5.0… but tbh the 5.1 and 5.2 changes seem small, and this seems to be working, so. Yeah ok let's roll!
2023-08-02 16:05:02 -07:00
nio4r (~> 2.0)
websocket-driver (>= 0.6.1)
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
zeitwerk (~> 2.6)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
actionmailbox (7.2.1)
actionpack (= 7.2.1)
activejob (= 7.2.1)
activerecord (= 7.2.1)
activestorage (= 7.2.1)
activesupport (= 7.2.1)
mail (>= 2.8.0)
actionmailer (7.2.1)
actionpack (= 7.2.1)
actionview (= 7.2.1)
activejob (= 7.2.1)
activesupport (= 7.2.1)
mail (>= 2.8.0)
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
rails-dom-testing (~> 2.2)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
actionpack (7.2.1)
actionview (= 7.2.1)
activesupport (= 7.2.1)
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
nokogiri (>= 1.8.5)
Upgrade to Rails 7.1.3.2 In response to: - https://discuss.rubyonrails.org/t/possible-xss-vulnerability-in-action-controller/84947 - https://discuss.rubyonrails.org/t/possible-redos-vulnerability-in-accept-header-parsing-in-action-dispatch/84946 No evidence that our app has been affected, but I like to move quickly on these!
2024-02-22 11:25:52 -08:00
racc
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
rack (>= 2.2.4, < 3.2)
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
rack-session (>= 1.0.1)
Upgrade to Rails 5.2.8.1 Some important little upgrades but mostly straightforward! Note that there's still a known issue where item searches crash, I was hoping that this was a bug in Rails 4.2 that would be fixed on upgading to 5, but nope, oh well! Also uhh I just got a bit silly and didn't actually mean to go all the way to 5.2 in one go, I had meant to start at 5.0… but tbh the 5.1 and 5.2 changes seem small, and this seems to be working, so. Yeah ok let's roll!
2023-08-02 16:05:02 -07:00
rack-test (>= 0.6.3)
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
rails-dom-testing (~> 2.2)
rails-html-sanitizer (~> 1.6)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
useragent (~> 0.16)
actiontext (7.2.1)
actionpack (= 7.2.1)
activerecord (= 7.2.1)
activestorage (= 7.2.1)
activesupport (= 7.2.1)
Upgrade to Rails 7.0.6 Whew! Seems like a pretty clean one? Ran `rails app:upgrade` and stuff, and made some corrections to keyword arguments for `translate` calls. There might be more such problems elsewhere? But that's hard to search for, and we'll have to see.
2023-08-03 16:37:45 -07:00
globalid (>= 0.6.0)
Upgrade to Rails 6.0.6.1 Another pretty easy one! We have the `rails app:update` changes in here too.
2023-08-02 17:27:11 -07:00
nokogiri (>= 1.8.5)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
actionview (7.2.1)
activesupport (= 7.2.1)
Update gems to Rails 4.1 (crashes!) Lookin' good on this end, but the server isn't starting up yet, got some fixes to make!
2023-07-29 11:33:39 -07:00
builder (~> 3.1)
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
erubi (~> 1.11)
rails-dom-testing (~> 2.2)
rails-html-sanitizer (~> 1.6)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
activejob (7.2.1)
activesupport (= 7.2.1)
Upgrade to Rails 5.2.8.1 Some important little upgrades but mostly straightforward! Note that there's still a known issue where item searches crash, I was hoping that this was a bug in Rails 4.2 that would be fixed on upgading to 5, but nope, oh well! Also uhh I just got a bit silly and didn't actually mean to go all the way to 5.2 in one go, I had meant to start at 5.0… but tbh the 5.1 and 5.2 changes seem small, and this seems to be working, so. Yeah ok let's roll!
2023-08-02 16:05:02 -07:00
globalid (>= 0.3.6)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
activemodel (7.2.1)
activesupport (= 7.2.1)
activerecord (7.2.1)
activemodel (= 7.2.1)
activesupport (= 7.2.1)
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
timeout (>= 0.4.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
activestorage (7.2.1)
actionpack (= 7.2.1)
activejob (= 7.2.1)
activerecord (= 7.2.1)
activesupport (= 7.2.1)
Upgrade to Rails 6.0.6.1 Another pretty easy one! We have the `rails app:update` changes in here too.
2023-08-02 17:27:11 -07:00
marcel (~> 1.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
activesupport (7.2.1)
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
base64
bigdecimal
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
concurrent-ruby (~> 1.0, >= 1.3.1)
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
connection_pool (>= 2.2.5)
drb
Upgrade to Rails 6.1.7.4 This one was pretty straightforward yaay! Main thing was the change from `render file` to `render template` in a couple places, oh and a thing with complex `order()` clauses.
2023-08-02 17:55:32 -07:00
i18n (>= 1.6, < 2)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
logger (>= 1.4.2)
Upgrade to Rails 6.1.7.4 This one was pretty straightforward yaay! Main thing was the change from `render file` to `render template` in a couple places, oh and a thing with complex `order()` clauses.
2023-08-02 17:55:32 -07:00
minitest (>= 5.1)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
securerandom (>= 0.3)
tzinfo (~> 2.0, >= 2.0.5)
addressable (2.8.7)
public_suffix (>= 2.0.2, < 7.0)
Refactor to use OpenID Connect OmniAuth gem instead of plain OAuth2 Right, I didn't totally connect the dots that there's some OpenID features in the mix here for how we expect to identify the user once they authenticate. It requires looking up the provider's public key, and validating the JWT they sent us. This gem does all that for us! I don't actually know what a real NeoPass `id_token` looks like yet? But I'll fill in some placeholder stuff for now, and use that for initializing the account!
2024-03-14 18:11:40 -07:00
aes_key_wrap (1.1.0)
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
ast (2.4.2)
Upgrade async and related gems, and fix async-http response handling When playing with a Rainbow Pool syncing task, I noticed that error handling wasn't working correctly for requests using `async-http`: if the block raised an error, the `Sync` block would never return. My suspicion is that this is because we were never reading or releasing the request body. In this change, I upgrade all the relevant gems for good measure, and switch to using the response object yielded by the _block_, so we can know it's being resource-managed correctly. Now, failures raise errors as expected! (I tested all these relevant service calls, too!)
2024-09-07 12:14:12 -07:00
async (2.17.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
console (~> 1.26)
Move manifest backfill to `swf_assets:manifests` task Okay, I've simplified the migration to *just* add the column, and instead added a task to find assets without manifest URLs and backfill them. Performance is a lot better now, using the `async-http` library, which as I understand it supports both persistent connections when invoked like this, and maybe also HTTP/2 multiplexing?? (Though I'm not actually sure images.neopets.com does lol) I'm not sure about the number of concurrent tasks I picked here, 100 seems okay for an internet thing and for such small requests, but I worry that the CDN is gonna get annoyed or something. Well, we'll see! This task is very resumable if it turns out we get frozen out or something.
2023-11-10 16:52:50 -08:00
fiber-annotation
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
io-event (~> 1.6, >= 1.6.5)
Upgrade async and related gems, and fix async-http response handling When playing with a Rainbow Pool syncing task, I noticed that error handling wasn't working correctly for requests using `async-http`: if the block raised an error, the `Sync` block would never return. My suspicion is that this is because we were never reading or releasing the request body. In this change, I upgrade all the relevant gems for good measure, and switch to using the response object yielded by the _block_, so we can know it's being resource-managed correctly. Now, failures raise errors as expected! (I tested all these relevant service calls, too!)
2024-09-07 12:14:12 -07:00
async-container (0.18.3)
async (~> 2.10)
async-http (0.75.0)
async (>= 2.10.2)
async-pool (~> 0.7)
io-endpoint (~> 0.11)
io-stream (~> 0.4)
protocol-http (~> 0.30)
protocol-http1 (~> 0.20)
protocol-http2 (~> 0.18)
traces (>= 0.10)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
async-http-cache (0.4.4)
Replace falcon server with puma Been wanting this for a while in theory, gonna actually do it now! The motivation is that I want to turn up the timeout for loading pets, because the Neopets endpoints are slower today with the NC UC release - but I can already predict that under our current architecture that will be a problem, because it'll block up our request queue! Falcon uses Ruby's relatively-new async system to *not* have requests block on upstream requests, and my understanding is that this behavior is plug-and-play. Let's see how it goes!
2024-01-23 21:47:51 -08:00
async-http (~> 0.56)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
async-pool (0.8.1)
Move manifest backfill to `swf_assets:manifests` task Okay, I've simplified the migration to *just* add the column, and instead added a task to find assets without manifest URLs and backfill them. Performance is a lot better now, using the `async-http` library, which as I understand it supports both persistent connections when invoked like this, and maybe also HTTP/2 multiplexing?? (Though I'm not actually sure images.neopets.com does lol) I'm not sure about the number of concurrent tasks I picked here, 100 seems okay for an internet thing and for such small requests, but I worry that the CDN is gonna get annoyed or something. Well, we'll see! This task is very resumable if it turns out we get frozen out or something.
2023-11-10 16:52:50 -08:00
async (>= 1.25)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
metrics
traces
Upgrade async and related gems, and fix async-http response handling When playing with a Rainbow Pool syncing task, I noticed that error handling wasn't working correctly for requests using `async-http`: if the block raised an error, the `Sync` block would never return. My suspicion is that this is because we were never reading or releasing the request body. In this change, I upgrade all the relevant gems for good measure, and switch to using the response object yielded by the _block_, so we can know it's being resource-managed correctly. Now, failures raise errors as expected! (I tested all these relevant service calls, too!)
2024-09-07 12:14:12 -07:00
async-service (0.12.0)
async
async-container (~> 0.16)
Refactor to use OpenID Connect OmniAuth gem instead of plain OAuth2 Right, I didn't totally connect the dots that there's some OpenID features in the mix here for how we expect to identify the user once they authenticate. It requires looking up the provider's public key, and validating the JWT they sent us. This gem does all that for us! I don't actually know what a real NeoPass `id_token` looks like yet? But I'll fill in some placeholder stuff for now, and use that for initializing the account!
2024-03-14 18:11:40 -07:00
attr_required (1.0.2)
Upgrade to Ruby 2.2.4, Rails 4.0.13 NOTE: This doesn't boot yet! There's something changed in the `devise` API that we'll need to fix! ``` /vagrant/config/initializers/devise.rb:46:in `block in <top (required)>': undefined method `encryptor=' for Devise:Module (NoMethodError) ``` But yeah, we navigated the gem upgrades, and also I ran `rake rails:update` and hand-processed the suggestions it had for our config files.
2023-07-21 19:39:32 -07:00
babel-source (5.8.35)
babel-transpiler (0.7.0)
babel-source (>= 4.0, < 6)
execjs (~> 2.0)
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
backport (1.2.0)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
base64 (0.2.0)
bcrypt (3.1.20)
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
benchmark (0.3.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
bigdecimal (3.1.8)
Refactor to use OpenID Connect OmniAuth gem instead of plain OAuth2 Right, I didn't totally connect the dots that there's some OpenID features in the mix here for how we expect to identify the user once they authenticate. It requires looking up the provider's public key, and validating the JWT they sent us. This gem does all that for us! I don't actually know what a real NeoPass `id_token` looks like yet? But I'll fill in some placeholder stuff for now, and use that for initializing the account!
2024-03-14 18:11:40 -07:00
bindata (2.5.0)
Upgrade web-console Huh, error pages weren't actually working on this older version of web-console, but now they are! Solution found here: https://discuss.rubyonrails.org/t/question-dev-mode-500-errors-not-displayed-config-consider-all-requests-local-not-honored/78453/7
2023-08-02 16:20:50 -07:00
bindex (0.8.1)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
bootsnap (1.18.4)
Run `rails app:update` We accepted some changes as-is, but for development.rb and production.rb we read the diff and manually edited them!
2023-08-02 16:17:07 -07:00
msgpack (~> 1.2)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
builder (3.3.0)
childprocess (5.1.0)
logger (~> 1.5)
concurrent-ruby (1.3.4)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
connection_pool (2.4.1)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
console (1.27.0)
Move manifest backfill to `swf_assets:manifests` task Okay, I've simplified the migration to *just* add the column, and instead added a task to find assets without manifest URLs and backfill them. Performance is a lot better now, using the `async-http` library, which as I understand it supports both persistent connections when invoked like this, and maybe also HTTP/2 multiplexing?? (Though I'm not actually sure images.neopets.com does lol) I'm not sure about the number of concurrent tasks I picked here, 100 seems okay for an internet thing and for such small requests, but I worry that the CDN is gonna get annoyed or something. Well, we'll see! This task is very resumable if it turns out we get frozen out or something.
2023-11-10 16:52:50 -08:00
fiber-annotation
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
fiber-local (~> 1.1)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
json
Upgrade to Rails 4.2.11.3 and Ruby 2.4.10 Some tricks required here to get the dependencies to work out, but we got it!! Oh also, we move away from the rbenv in Ubuntu's package manager, because it doesn't support more recent Rubies like 2.4.10.
2023-08-02 15:18:36 -07:00
crass (1.0.6)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
csv (3.3.0)
Upgrade to Rails 7.1.3.2 In response to: - https://discuss.rubyonrails.org/t/possible-xss-vulnerability-in-action-controller/84947 - https://discuss.rubyonrails.org/t/possible-redos-vulnerability-in-accept-header-parsing-in-action-dispatch/84946 No evidence that our app has been affected, but I like to move quickly on these!
2024-02-22 11:25:52 -08:00
date (3.3.4)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
devise (4.9.4)
Upgrade to Ruby 2.2.4, Rails 4.0.13 NOTE: This doesn't boot yet! There's something changed in the `devise` API that we'll need to fix! ``` /vagrant/config/initializers/devise.rb:46:in `block in <top (required)>': undefined method `encryptor=' for Devise:Module (NoMethodError) ``` But yeah, we navigated the gem upgrades, and also I ran `rake rails:update` and hand-processed the suggestions it had for our config files.
2023-07-21 19:39:32 -07:00
bcrypt (~> 3.0)
phew. rails 3.2.12, including some asset pipeline. still buggy.
2013-03-05 18:08:57 -08:00
orm_adapter (~> 0.1)
Upgrade to Rails 4.2.11.3 and Ruby 2.4.10 Some tricks required here to get the dependencies to work out, but we got it!! Oh also, we move away from the rbenv in Ubuntu's package manager, because it doesn't support more recent Rubies like 2.4.10.
2023-08-02 15:18:36 -07:00
railties (>= 4.1.0)
Upgrade to Ruby 2.2.4, Rails 4.0.13 NOTE: This doesn't boot yet! There's something changed in the `devise` API that we'll need to fix! ``` /vagrant/config/initializers/devise.rb:46:in `block in <top (required)>': undefined method `encryptor=' for Devise:Module (NoMethodError) ``` But yeah, we navigated the gem upgrades, and also I ran `rake rails:update` and hand-processed the suggestions it had for our config files.
2023-07-21 19:39:32 -07:00
responders
warden (~> 1.2.3)
Can log into OpenNeo ID accounts directly! A lot of rough edges here (e.g. no styles on the flash messages), but it's working and that's good!! I tested this by temporarily switching to the production database and logging in as matchu! Still missing a lot of big features too, like registration, password resets, settings page, etc.
2023-08-06 15:52:05 -07:00
devise-encryptable (0.2.0)
devise (>= 2.1.0)
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
diff-lcs (1.5.1)
Remove dotenv-deployment, upgrade dotenv-rails Idk exactly what's going on with dotenv-deployment, if it turns out it was critical to our deploy process then we'll change the deploy process! It's deprecated and conflicts with gem deps for `dotenv-rails`.
2023-08-02 13:41:37 -07:00
dotenv (2.8.1)
dotenv-rails (2.8.1)
dotenv (= 2.8.1)
railties (>= 3.2)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
drb (2.2.1)
Create `rails public_data:commit` task, to share public data dumps I'm starting to port over the functionality that was previously just, me running `yarn db:export:public-data` in `impress-2020` and committing it to Git LFS every time. My immediate motivation is that the `impress-2020` git repository is getting weirdly large?? Idk how these 40MB files have blown up to a solid 16GB of Git LFS data (we don't have THAT many!!!), but I guess there's something about Git LFS's architecture and disk usage that I'm not understanding. So, let's move to a simpler system in which we don't bind the public data to the codebase, but instead just regularly dump it in production and make it available for download. This change adds the `rails public_data:commit` task, which when run in production will make the latest available at `https://impress.openneo.net/public-data/latest.sql.gz`, and will also store a running log of previous dumps, viewable at `https://impress.openneo.net/public-data/`. Things left to do: 1. Create a `rails public_data:pull` task, to download `latest.sql.gz` and import it into the local development database. 2. Set up a cron job to dump this out regularly, idk maybe weekly? That will grow, but not very fast (about 2GB per year), and we can add logic to rotate out old ones if it starts to grow too far. (If we wanted to get really intricate, we could do like, daily for the past week, then weekly for the past 3 months, then monthly for the past year, idk. There must be tools that do this!)
2024-02-29 14:30:33 -08:00
e2mmap (0.1.0)
Refactor to use OpenID Connect OmniAuth gem instead of plain OAuth2 Right, I didn't totally connect the dots that there's some OpenID features in the mix here for how we expect to identify the user once they authenticate. It requires looking up the provider's public key, and validating the JWT they sent us. This gem does all that for us! I don't actually know what a real NeoPass `id_token` looks like yet? But I'll fill in some placeholder stuff for now, and use that for initializing the account!
2024-03-14 18:11:40 -07:00
email_validator (2.2.4)
activemodel
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
erubi (1.13.0)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
execjs (2.9.1)
Run `bundle update`
2024-09-26 12:42:18 -07:00
falcon (0.48.2)
Replace falcon server with puma Been wanting this for a while in theory, gonna actually do it now! The motivation is that I want to turn up the timeout for loading pets, because the Neopets endpoints are slower today with the NC UC release - but I can already predict that under our current architecture that will be a problem, because it'll block up our request queue! Falcon uses Ruby's relatively-new async system to *not* have requests block on upstream requests, and my understanding is that this behavior is plug-and-play. Let's see how it goes!
2024-01-23 21:47:51 -08:00
async
Upgrade async and related gems, and fix async-http response handling When playing with a Rainbow Pool syncing task, I noticed that error handling wasn't working correctly for requests using `async-http`: if the block raised an error, the `Sync` block would never return. My suspicion is that this is because we were never reading or releasing the request body. In this change, I upgrade all the relevant gems for good measure, and switch to using the response object yielded by the _block_, so we can know it's being resource-managed correctly. Now, failures raise errors as expected! (I tested all these relevant service calls, too!)
2024-09-07 12:14:12 -07:00
async-container (~> 0.18)
async-http (~> 0.75)
async-http-cache (~> 0.4)
async-service (~> 0.10)
Replace falcon server with puma Been wanting this for a while in theory, gonna actually do it now! The motivation is that I want to turn up the timeout for loading pets, because the Neopets endpoints are slower today with the NC UC release - but I can already predict that under our current architecture that will be a problem, because it'll block up our request queue! Falcon uses Ruby's relatively-new async system to *not* have requests block on upstream requests, and my understanding is that this behavior is plug-and-play. Let's see how it goes!
2024-01-23 21:47:51 -08:00
bundler
localhost (~> 1.1)
openssl (~> 3.0)
Upgrade async and related gems, and fix async-http response handling When playing with a Rainbow Pool syncing task, I noticed that error handling wasn't working correctly for requests using `async-http`: if the block raised an error, the `Sync` block would never return. My suspicion is that this is because we were never reading or releasing the request body. In this change, I upgrade all the relevant gems for good measure, and switch to using the response object yielded by the _block_, so we can know it's being resource-managed correctly. Now, failures raise errors as expected! (I tested all these relevant service calls, too!)
2024-09-07 12:14:12 -07:00
process-metrics (~> 0.2)
protocol-http (~> 0.31)
protocol-rack (~> 0.7)
samovar (~> 2.3)
Run `bundle update`
2024-09-26 12:42:18 -07:00
faraday (2.12.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
faraday-net_http (>= 2.0, < 3.4)
Run `bundle update`
2024-09-26 12:42:18 -07:00
json
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
logger
Refactor to use OpenID Connect OmniAuth gem instead of plain OAuth2 Right, I didn't totally connect the dots that there's some OpenID features in the mix here for how we expect to identify the user once they authenticate. It requires looking up the provider's public key, and validating the JWT they sent us. This gem does all that for us! I don't actually know what a real NeoPass `id_token` looks like yet? But I'll fill in some placeholder stuff for now, and use that for initializing the account!
2024-03-14 18:11:40 -07:00
faraday-follow_redirects (0.3.0)
faraday (>= 1, < 3)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
faraday-net_http (3.3.0)
NeoPass strategy interacts with dev NeoPass server, which is still WIP In this change, we wire up a new NeoPass OAuth2 strategy for OmniAuth, and hook up the "Log in with NeoPass" button to use it! The authentication currently fails with `invalid_credentials`, and shows the `owo` response we hardcoded into the NeoPass server's token response. We need to finally follow up on the little `TODO` written in there!
2024-03-14 16:13:31 -07:00
net-http
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
ffi (1.17.0)
Move manifest backfill to `swf_assets:manifests` task Okay, I've simplified the migration to *just* add the column, and instead added a task to find assets without manifest URLs and backfill them. Performance is a lot better now, using the `async-http` library, which as I understand it supports both persistent connections when invoked like this, and maybe also HTTP/2 multiplexing?? (Though I'm not actually sure images.neopets.com does lol) I'm not sure about the number of concurrent tasks I picked here, 100 seems okay for an internet thing and for such small requests, but I worry that the CDN is gonna get annoyed or something. Well, we'll see! This task is very resumable if it turns out we get frozen out or something.
2023-11-10 16:52:50 -08:00
fiber-annotation (0.2.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
fiber-local (1.1.0)
fiber-storage
fiber-storage (1.0.0)
Security updates Resolves CVE-2023-40175 and CVE-2023-38037.
2023-10-23 19:08:56 -07:00
globalid (1.2.1)
activesupport (>= 6.1)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
haml (6.3.0)
Upgrade haml I was hoping this would fix a character encoding bug, it didn't really? but it doesn't seem to hurt and is probably good to do
2023-07-22 12:58:15 -07:00
temple (>= 0.8.2)
thor
phew. rails 3.2.12, including some asset pipeline. still buggy.
2013-03-05 18:08:57 -08:00
tilt
Add OmniAuth plugin to AuthUser This is setting us up for NeoPass, but first we're just gonna try stuff with the "developer" strategy that's built in for testing, rather than using the NeoPass dev server!
2024-03-13 13:10:59 -07:00
hashie (5.0.0)
Version the http_accept_languages gem idk why we were pulling from git before, probably to get a feature that wasn't pushed to rubygems yet? But now the latest rubygems version matches the latest repo commit (both back in 2017 lol), so let's do that for greater stability and clarity!
2023-08-02 13:24:56 -07:00
http_accept_language (2.1.1)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
httparty (0.22.0)
csv
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
mini_mime (>= 1.0.0)
multi_xml (>= 0.5.2)
Run `bundle update`
2024-09-26 12:42:18 -07:00
i18n (1.14.6)
Upgrade to Rails 3.2.22.5 I'm just giving the app a very quick scan on critical pages, it's possible I'm missing some issues on paths that are harder to test rn like openneo_id auth, but I'll check in on that later I think?
2023-07-21 18:33:04 -07:00
concurrent-ruby (~> 1.0)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
io-console (0.7.2)
Upgrade async and related gems, and fix async-http response handling When playing with a Rainbow Pool syncing task, I noticed that error handling wasn't working correctly for requests using `async-http`: if the block raised an error, the `Sync` block would never return. My suspicion is that this is because we were never reading or releasing the request body. In this change, I upgrade all the relevant gems for good measure, and switch to using the response object yielded by the _block_, so we can know it's being resource-managed correctly. Now, failures raise errors as expected! (I tested all these relevant service calls, too!)
2024-09-07 12:14:12 -07:00
io-endpoint (0.13.1)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
io-event (1.6.5)
Run `bundle update`
2024-09-26 12:42:18 -07:00
io-stream (0.4.1)
irb (1.14.1)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
rdoc (>= 4.0.0)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
reline (>= 0.4.2)
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
jaro_winkler (1.6.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
jsbundling-rails (1.3.1)
Bundle wardrobe-2020 into the app We add jsbuilding-rails to get esbuild running in the app, and then we copy-paste the files we need from impress-2020 into here! I stopped at the point where it was building successfully, but it's not running correctly: it's not sure about `process.env` in `next`, and I think the right next step is to delete the NextJS deps altogether and use React Router instead.
2023-08-10 15:56:36 -07:00
railties (>= 6.0.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
json (2.7.2)
Refactor to use OpenID Connect OmniAuth gem instead of plain OAuth2 Right, I didn't totally connect the dots that there's some OpenID features in the mix here for how we expect to identify the user once they authenticate. It requires looking up the provider's public key, and validating the JWT they sent us. This gem does all that for us! I don't actually know what a real NeoPass `id_token` looks like yet? But I'll fill in some placeholder stuff for now, and use that for initializing the account!
2024-03-14 18:11:40 -07:00
json-jwt (1.16.6)
activesupport (>= 4.2)
aes_key_wrap
NeoPass strategy interacts with dev NeoPass server, which is still WIP In this change, we wire up a new NeoPass OAuth2 strategy for OmniAuth, and hook up the "Log in with NeoPass" button to use it! The authentication currently fails with `invalid_credentials`, and shows the `owo` response we hardcoded into the NeoPass server's token response. We need to finally follow up on the little `TODO` written in there!
2024-03-14 16:13:31 -07:00
base64
Refactor to use OpenID Connect OmniAuth gem instead of plain OAuth2 Right, I didn't totally connect the dots that there's some OpenID features in the mix here for how we expect to identify the user once they authenticate. It requires looking up the provider's public key, and validating the JWT they sent us. This gem does all that for us! I don't actually know what a real NeoPass `id_token` looks like yet? But I'll fill in some placeholder stuff for now, and use that for initializing the account!
2024-03-14 18:11:40 -07:00
bindata
faraday (~> 2.0)
faraday-follow_redirects
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
kramdown (2.4.0)
rexml
kramdown-parser-gfm (1.1.0)
kramdown (~> 2.0)
language_server-protocol (3.17.0.3)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
launchy (3.0.1)
Update all our gems as far as we can Got pretty far, there's a couple still held back by Rails 6+, but yeah doing great!
2023-08-02 17:16:24 -07:00
addressable (~> 2.8)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
childprocess (~> 5.0)
letter_opener (1.10.0)
launchy (>= 2.2, < 4)
localhost (1.3.1)
Run `bundle update`
2024-09-26 12:42:18 -07:00
logger (1.6.1)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
loofah (2.22.0)
Upgrade to Rails 4.2.11.3 and Ruby 2.4.10 Some tricks required here to get the dependencies to work out, but we got it!! Oh also, we move away from the rbenv in Ubuntu's package manager, because it doesn't support more recent Rubies like 2.4.10.
2023-08-02 15:18:36 -07:00
crass (~> 1.0.2)
Fix gems we'd locked to old versions Now that we're on Ruby 2.6, the constraints on the latest versions of these dependencies are satisfied, so we can stop holding them back!
2023-08-02 17:09:43 -07:00
nokogiri (>= 1.12.0)
mail (2.8.1)
Upgrade to Ruby 2.2.4, Rails 4.0.13 NOTE: This doesn't boot yet! There's something changed in the `devise` API that we'll need to fix! ``` /vagrant/config/initializers/devise.rb:46:in `block in <top (required)>': undefined method `encryptor=' for Devise:Module (NoMethodError) ``` But yeah, we navigated the gem upgrades, and also I ran `rake rails:update` and hand-processed the suggestions it had for our config files.
2023-07-21 19:39:32 -07:00
mini_mime (>= 0.1.1)
Fix gems we'd locked to old versions Now that we're on Ruby 2.6, the constraints on the latest versions of these dependencies are satisfied, so we can stop holding them back!
2023-08-02 17:09:43 -07:00
net-imap
net-pop
net-smtp
Replace falcon server with puma Been wanting this for a while in theory, gonna actually do it now! The motivation is that I want to turn up the timeout for loading pets, because the Neopets endpoints are slower today with the NC UC release - but I can already predict that under our current architecture that will be a problem, because it'll block up our request queue! Falcon uses Ruby's relatively-new async system to *not* have requests block on upstream requests, and my understanding is that this behavior is plug-and-play. Let's see how it goes!
2024-01-23 21:47:51 -08:00
mapping (1.1.1)
Upgrade to Rails 7.1.3.4 Motivated by a security patch, I don't think we're affected by it but whatever, it's a convenient time to get it done!
2024-06-04 11:32:51 -07:00
marcel (1.0.4)
Run `bundle update`
2024-09-26 12:42:18 -07:00
memory_profiler (1.1.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
metrics (0.10.2)
Security updates Resolves CVE-2023-40175 and CVE-2023-38037.
2023-10-23 19:08:56 -07:00
mini_mime (1.1.5)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
mini_portile2 (2.8.7)
minitest (5.25.1)
Update all our gems as far as we can Got pretty far, there's a couple still held back by Rails 6+, but yeah doing great!
2023-08-02 17:16:24 -07:00
msgpack (1.7.2)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
multi_xml (0.7.1)
bigdecimal (~> 3.1)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
mysql2 (0.5.6)
NeoPass strategy interacts with dev NeoPass server, which is still WIP In this change, we wire up a new NeoPass OAuth2 strategy for OmniAuth, and hook up the "Log in with NeoPass" button to use it! The authentication currently fails with `invalid_credentials`, and shows the `owo` response we hardcoded into the NeoPass server's token response. We need to finally follow up on the little `TODO` written in there!
2024-03-14 16:13:31 -07:00
net-http (0.4.1)
uri
Run `bundle update`
2024-09-26 12:42:18 -07:00
net-imap (0.4.16)
Fix gems we'd locked to old versions Now that we're on Ruby 2.6, the constraints on the latest versions of these dependencies are satisfied, so we can stop holding them back!
2023-08-02 17:09:43 -07:00
date
net-protocol
net-pop (0.1.2)
net-protocol
Upgrade to Rails 7.1.3.2 In response to: - https://discuss.rubyonrails.org/t/possible-xss-vulnerability-in-action-controller/84947 - https://discuss.rubyonrails.org/t/possible-redos-vulnerability-in-accept-header-parsing-in-action-dispatch/84946 No evidence that our app has been affected, but I like to move quickly on these!
2024-02-22 11:25:52 -08:00
net-protocol (0.2.2)
Fix gems we'd locked to old versions Now that we're on Ruby 2.6, the constraints on the latest versions of these dependencies are satisfied, so we can stop holding them back!
2023-08-02 17:09:43 -07:00
timeout
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
net-smtp (0.5.0)
Fix gems we'd locked to old versions Now that we're on Ruby 2.6, the constraints on the latest versions of these dependencies are satisfied, so we can stop holding them back!
2023-08-02 17:09:43 -07:00
net-protocol
Upgrade to Rails 7.1.3.4 Motivated by a security patch, I don't think we're affected by it but whatever, it's a convenient time to get it done!
2024-06-04 11:32:51 -07:00
nio4r (2.7.3)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
nokogiri (1.16.7)
Upgrade to Rails 7.0.6 Whew! Seems like a pretty clean one? Ran `rails app:upgrade` and stuff, and made some corrections to keyword arguments for `translate` calls. There might be more such problems elsewhere? But that's hard to search for, and we'll have to see.
2023-08-03 16:37:45 -07:00
mini_portile2 (~> 2.8.2)
Fix gems we'd locked to old versions Now that we're on Ruby 2.6, the constraints on the latest versions of these dependencies are satisfied, so we can stop holding them back!
2023-08-02 17:09:43 -07:00
racc (~> 1.4)
Add OmniAuth plugin to AuthUser This is setting us up for NeoPass, but first we're just gonna try stuff with the "developer" strategy that's built in for testing, rather than using the NeoPass dev server!
2024-03-13 13:10:59 -07:00
omniauth (2.1.2)
hashie (>= 3.4.6)
rack (>= 2.2.3)
rack-protection
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
omniauth-rails_csrf_protection (1.0.2)
Add OmniAuth plugin to AuthUser This is setting us up for NeoPass, but first we're just gonna try stuff with the "developer" strategy that's built in for testing, rather than using the NeoPass dev server!
2024-03-13 13:10:59 -07:00
actionpack (>= 4.2)
omniauth (~> 2.0)
Refactor to use OpenID Connect OmniAuth gem instead of plain OAuth2 Right, I didn't totally connect the dots that there's some OpenID features in the mix here for how we expect to identify the user once they authenticate. It requires looking up the provider's public key, and validating the JWT they sent us. This gem does all that for us! I don't actually know what a real NeoPass `id_token` looks like yet? But I'll fill in some placeholder stuff for now, and use that for initializing the account!
2024-03-14 18:11:40 -07:00
omniauth_openid_connect (0.7.1)
omniauth (>= 1.9, < 3)
openid_connect (~> 2.2)
openid_connect (2.3.0)
activemodel
attr_required (>= 1.0.0)
email_validator
faraday (~> 2.0)
faraday-follow_redirects
json-jwt (>= 1.16)
mail
rack-oauth2 (~> 2.2)
swd (~> 2.0)
tzinfo
validate_url
webfinger (~> 2.0)
Replace falcon server with puma Been wanting this for a while in theory, gonna actually do it now! The motivation is that I want to turn up the timeout for loading pets, because the Neopets endpoints are slower today with the NC UC release - but I can already predict that under our current architecture that will be a problem, because it'll block up our request queue! Falcon uses Ruby's relatively-new async system to *not* have requests block on upstream requests, and my understanding is that this behavior is plug-and-play. Let's see how it goes!
2024-01-23 21:47:51 -08:00
openssl (3.2.0)
improve app infrastructure to make a dev environment easier to reproduce This commit will require a few changes to the deployment process: * store AWS credentials in AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY env vars * store OpenNeo Auth credentials in OPENNEO_AUTH_APP, OPENNEO_AUTH_SERVER, and OPENNEO_AUTH_SECRET env vars STRIPE_SECRET_KEY and STRIPE_PUBLISHABLE_KEY are now required, too; better have a good .env. You can always put in dummy values if you have no credentials, though; they only get called up if there's a transaction. SECRET_TOKEN is now an env var, too, but the production deploy process currently replaces config/initializers/secret_token.rb anyway; this might be the way to go later, though.
2015-07-16 14:44:52 -07:00
orm_adapter (0.5.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
parallel (1.26.3)
Run `bundle update`
2024-09-26 12:42:18 -07:00
parser (3.3.5.0)
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
ast (~> 2.4.1)
racc
Upgrade async and related gems, and fix async-http response handling When playing with a Rainbow Pool syncing task, I noticed that error handling wasn't working correctly for requests using `async-http`: if the block raised an error, the `Sync` block would never return. My suspicion is that this is because we were never reading or releasing the request body. In this change, I upgrade all the relevant gems for good measure, and switch to using the response object yielded by the _block_, so we can know it's being resource-managed correctly. Now, failures raise errors as expected! (I tested all these relevant service calls, too!)
2024-09-07 12:14:12 -07:00
process-metrics (0.3.0)
Replace falcon server with puma Been wanting this for a while in theory, gonna actually do it now! The motivation is that I want to turn up the timeout for loading pets, because the Neopets endpoints are slower today with the NC UC release - but I can already predict that under our current architecture that will be a problem, because it'll block up our request queue! Falcon uses Ruby's relatively-new async system to *not* have requests block on upstream requests, and my understanding is that this behavior is plug-and-play. Let's see how it goes!
2024-01-23 21:47:51 -08:00
console (~> 1.8)
Upgrade async and related gems, and fix async-http response handling When playing with a Rainbow Pool syncing task, I noticed that error handling wasn't working correctly for requests using `async-http`: if the block raised an error, the `Sync` block would never return. My suspicion is that this is because we were never reading or releasing the request body. In this change, I upgrade all the relevant gems for good measure, and switch to using the response object yielded by the _block_, so we can know it's being resource-managed correctly. Now, failures raise errors as expected! (I tested all these relevant service calls, too!)
2024-09-07 12:14:12 -07:00
json (~> 2)
Replace falcon server with puma Been wanting this for a while in theory, gonna actually do it now! The motivation is that I want to turn up the timeout for loading pets, because the Neopets endpoints are slower today with the NC UC release - but I can already predict that under our current architecture that will be a problem, because it'll block up our request queue! Falcon uses Ruby's relatively-new async system to *not* have requests block on upstream requests, and my understanding is that this behavior is plug-and-play. Let's see how it goes!
2024-01-23 21:47:51 -08:00
samovar (~> 2.1)
Run `bundle update`
2024-09-26 12:42:18 -07:00
protocol-hpack (1.5.1)
protocol-http (0.37.0)
protocol-http1 (0.27.0)
Move manifest backfill to `swf_assets:manifests` task Okay, I've simplified the migration to *just* add the column, and instead added a task to find assets without manifest URLs and backfill them. Performance is a lot better now, using the `async-http` library, which as I understand it supports both persistent connections when invoked like this, and maybe also HTTP/2 multiplexing?? (Though I'm not actually sure images.neopets.com does lol) I'm not sure about the number of concurrent tasks I picked here, 100 seems okay for an internet thing and for such small requests, but I worry that the CDN is gonna get annoyed or something. Well, we'll see! This task is very resumable if it turns out we get frozen out or something.
2023-11-10 16:52:50 -08:00
protocol-http (~> 0.22)
Run `bundle update`
2024-09-26 12:42:18 -07:00
protocol-http2 (0.19.1)
Move manifest backfill to `swf_assets:manifests` task Okay, I've simplified the migration to *just* add the column, and instead added a task to find assets without manifest URLs and backfill them. Performance is a lot better now, using the `async-http` library, which as I understand it supports both persistent connections when invoked like this, and maybe also HTTP/2 multiplexing?? (Though I'm not actually sure images.neopets.com does lol) I'm not sure about the number of concurrent tasks I picked here, 100 seems okay for an internet thing and for such small requests, but I worry that the CDN is gonna get annoyed or something. Well, we'll see! This task is very resumable if it turns out we get frozen out or something.
2023-11-10 16:52:50 -08:00
protocol-hpack (~> 1.4)
protocol-http (~> 0.18)
Run `bundle update`
2024-09-26 12:42:18 -07:00
protocol-rack (0.10.0)
protocol-http (~> 0.37)
Replace falcon server with puma Been wanting this for a while in theory, gonna actually do it now! The motivation is that I want to turn up the timeout for loading pets, because the Neopets endpoints are slower today with the NC UC release - but I can already predict that under our current architecture that will be a problem, because it'll block up our request queue! Falcon uses Ruby's relatively-new async system to *not* have requests block on upstream requests, and my understanding is that this behavior is plug-and-play. Let's see how it goes!
2024-01-23 21:47:51 -08:00
rack (>= 1.0)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
psych (5.1.2)
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
stringio
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
public_suffix (6.0.1)
racc (1.8.1)
rack (3.1.7)
Update all our gems as far as we can Got pretty far, there's a couple still held back by Rails 6+, but yeah doing great!
2023-08-02 17:16:24 -07:00
rack-attack (6.7.0)
rack (>= 1.0, < 4)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
rack-mini-profiler (3.3.1)
Add mini profiler to each page It shows up in development always, and if you're logged in as Me Specifically in production! I'm using this to poke at memory usage for pages that seem suspicious. I don't know why our app reliably grows so large in RAM, but my hunch is that maybe there are some pages that just use a truly large amount to begin with - and I've learned Ruby doesn't release memory back after it's GC'd, it just grows the process and keeps the free space to itself in its own heap! So I'm just eyeing pages that I know *can* have a lot going on, and seeing what I find!
2023-10-27 19:38:49 -07:00
rack (>= 1.2.0)
Refactor to use OpenID Connect OmniAuth gem instead of plain OAuth2 Right, I didn't totally connect the dots that there's some OpenID features in the mix here for how we expect to identify the user once they authenticate. It requires looking up the provider's public key, and validating the JWT they sent us. This gem does all that for us! I don't actually know what a real NeoPass `id_token` looks like yet? But I'll fill in some placeholder stuff for now, and use that for initializing the account!
2024-03-14 18:11:40 -07:00
rack-oauth2 (2.2.1)
activesupport
attr_required
faraday (~> 2.0)
faraday-follow_redirects
json-jwt (>= 1.11.0)
rack (>= 2.1.0)
Add OmniAuth plugin to AuthUser This is setting us up for NeoPass, but first we're just gonna try stuff with the "developer" strategy that's built in for testing, rather than using the NeoPass dev server!
2024-03-13 13:10:59 -07:00
rack-protection (4.0.0)
base64 (>= 0.1.0)
rack (>= 3.0.0, < 4)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
rack-session (2.0.0)
rack (>= 3.0.0)
Upgrade to Rails 5.2.8.1 Some important little upgrades but mostly straightforward! Note that there's still a known issue where item searches crash, I was hoping that this was a bug in Rails 4.2 that would be fixed on upgading to 5, but nope, oh well! Also uhh I just got a bit silly and didn't actually mean to go all the way to 5.2 in one go, I had meant to start at 5.0… but tbh the 5.1 and 5.2 changes seem small, and this seems to be working, so. Yeah ok let's roll!
2023-08-02 16:05:02 -07:00
rack-test (2.1.0)
rack (>= 1.3)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
rackup (2.1.0)
rack (>= 3)
webrick (~> 1.8)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
rails (7.2.1)
actioncable (= 7.2.1)
actionmailbox (= 7.2.1)
actionmailer (= 7.2.1)
actionpack (= 7.2.1)
actiontext (= 7.2.1)
actionview (= 7.2.1)
activejob (= 7.2.1)
activemodel (= 7.2.1)
activerecord (= 7.2.1)
activestorage (= 7.2.1)
activesupport (= 7.2.1)
Upgrade to Rails 6.1.7.4 This one was pretty straightforward yaay! Main thing was the change from `render file` to `render template` in a couple places, oh and a thing with complex `order()` clauses.
2023-08-02 17:55:32 -07:00
bundler (>= 1.15.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
railties (= 7.2.1)
Upgrade to Rails 7.0.6 Whew! Seems like a pretty clean one? Ran `rails app:upgrade` and stuff, and made some corrections to keyword arguments for `translate` calls. There might be more such problems elsewhere? But that's hard to search for, and we'll have to see.
2023-08-03 16:37:45 -07:00
rails-dom-testing (2.2.0)
Upgrade to Rails 5.2.8.1 Some important little upgrades but mostly straightforward! Note that there's still a known issue where item searches crash, I was hoping that this was a bug in Rails 4.2 that would be fixed on upgading to 5, but nope, oh well! Also uhh I just got a bit silly and didn't actually mean to go all the way to 5.2 in one go, I had meant to start at 5.0… but tbh the 5.1 and 5.2 changes seem small, and this seems to be working, so. Yeah ok let's roll!
2023-08-02 16:05:02 -07:00
activesupport (>= 5.0.0)
minitest
nokogiri (>= 1.6)
Upgrade to Rails 7.0.6 Whew! Seems like a pretty clean one? Ran `rails app:upgrade` and stuff, and made some corrections to keyword arguments for `translate` calls. There might be more such problems elsewhere? But that's hard to search for, and we'll have to see.
2023-08-03 16:37:45 -07:00
rails-html-sanitizer (1.6.0)
loofah (~> 2.21)
nokogiri (~> 1.14)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
rails-i18n (7.0.9)
Upgrade to Rails 5.2.8.1 Some important little upgrades but mostly straightforward! Note that there's still a known issue where item searches crash, I was hoping that this was a bug in Rails 4.2 that would be fixed on upgading to 5, but nope, oh well! Also uhh I just got a bit silly and didn't actually mean to go all the way to 5.2 in one go, I had meant to start at 5.0… but tbh the 5.1 and 5.2 changes seem small, and this seems to be working, so. Yeah ok let's roll!
2023-08-02 16:05:02 -07:00
i18n (>= 0.7, < 2)
Upgrade to Rails 6.0.6.1 Another pretty easy one! We have the `rails app:update` changes in here too.
2023-08-02 17:27:11 -07:00
railties (>= 6.0.0, < 8)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
railties (7.2.1)
actionpack (= 7.2.1)
activesupport (= 7.2.1)
irb (~> 1.13)
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
rackup (>= 1.0.0)
Upgrade to Rails 6.1.7.4 This one was pretty straightforward yaay! Main thing was the change from `render file` to `render template` in a couple places, oh and a thing with complex `order()` clauses.
2023-08-02 17:55:32 -07:00
rake (>= 12.2)
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
thor (~> 1.0, >= 1.2.2)
zeitwerk (~> 2.6)
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
rainbow (3.1.1)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
rake (13.2.1)
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
rbs (2.8.4)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
rdiscount (2.2.7.3)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
rdoc (6.7.0)
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
psych (>= 4.0.0)
Upgrade to Ruby 2.2.4, Rails 4.0.13 NOTE: This doesn't boot yet! There's something changed in the `devise` API that we'll need to fix! ``` /vagrant/config/initializers/devise.rb:46:in `block in <top (required)>': undefined method `encryptor=' for Devise:Module (NoMethodError) ``` But yeah, we navigated the gem upgrades, and also I ran `rake rails:update` and hand-processed the suggestions it had for our config files.
2023-07-21 19:39:32 -07:00
react-rails (2.7.1)
babel-transpiler (>= 0.7.0)
connection_pool
basic modeling buttons no behavior yet, nor are they filtered
2014-01-03 13:11:02 -08:00
execjs
Upgrade to Ruby 2.2.4, Rails 4.0.13 NOTE: This doesn't boot yet! There's something changed in the `devise` API that we'll need to fix! ``` /vagrant/config/initializers/devise.rb:46:in `block in <top (required)>': undefined method `encryptor=' for Devise:Module (NoMethodError) ``` But yeah, we navigated the gem upgrades, and also I ran `rake rails:update` and hand-processed the suggestions it had for our config files.
2023-07-21 19:39:32 -07:00
railties (>= 3.2)
tilt
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
regexp_parser (2.9.2)
Run `bundle update`
2024-09-26 12:42:18 -07:00
reline (0.5.10)
Upgrade to Rails 7.1.1 The usual stuff! Installed the new gem and its new deps, ran `bin/rails app:update` and did my best to manually merge the dev/prod config files with the new canonical defaults, deleted some migrations I don't think are relevant to us, and yeah! Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that to the `deploy/setup.yml` playbook! One thing to note is that, while I was here, I turned on some settings relating to our use of SSL that technically weren't on before. This should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
io-console (~> 0.5)
responders (3.1.1)
Upgrade to Rails 6.0.6.1 Another pretty easy one! We have the `rails app:update` changes in here too.
2023-08-02 17:27:11 -07:00
actionpack (>= 5.2)
railties (>= 5.2)
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
reverse_markdown (2.1.1)
nokogiri
Run `bundle update`
2024-09-26 12:42:18 -07:00
rexml (3.3.7)
rubocop (1.66.1)
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
json (~> 2.3)
language_server-protocol (>= 3.17.0)
parallel (~> 1.10)
parser (>= 3.3.0.2)
rainbow (>= 2.2.2, < 4.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
regexp_parser (>= 2.4, < 3.0)
Run `bundle update`
2024-09-26 12:42:18 -07:00
rubocop-ast (>= 1.32.2, < 2.0)
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
ruby-progressbar (~> 1.7)
unicode-display_width (>= 2.4.0, < 3.0)
Run `bundle update`
2024-09-26 12:42:18 -07:00
rubocop-ast (1.32.3)
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
parser (>= 3.3.1.0)
ruby-progressbar (1.13.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
samovar (2.3.0)
Replace falcon server with puma Been wanting this for a while in theory, gonna actually do it now! The motivation is that I want to turn up the timeout for loading pets, because the Neopets endpoints are slower today with the NC UC release - but I can already predict that under our current architecture that will be a problem, because it'll block up our request queue! Falcon uses Ruby's relatively-new async system to *not* have requests block on upstream requests, and my understanding is that this behavior is plug-and-play. Let's see how it goes!
2024-01-23 21:47:51 -08:00
console (~> 1.0)
mapping (~> 1.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
sanitize (6.1.3)
Update all our gems as far as we can Got pretty far, there's a couple still held back by Rails 6+, but yeah doing great!
2023-08-02 17:16:24 -07:00
crass (~> 1.0.2)
nokogiri (>= 1.12.0)
Upgrade to latest Sass and Sprockets This required a buncha fixes to how SASS scoping works! Needed to add a bunch of imports for stuff that previously would get read from the global scope by being imported *after* the constants and mixins etc. There's clearly a lot of refactor opportunity here, but I'm not gonna worry about it!!
2023-08-22 16:08:11 -07:00
sass-rails (6.0.0)
sassc-rails (~> 2.1, >= 2.1.1)
sassc (2.4.0)
ffi (~> 1.9)
sassc-rails (2.1.2)
railties (>= 4.0.0)
sassc (>= 2.0)
sprockets (> 3.0)
sprockets-rails
tilt
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
securerandom (0.3.1)
sentry-rails (5.19.0)
Add Sentry to Rails Now we're tracking both JS and Rails errors, phew!
2023-11-06 12:37:40 -08:00
railties (>= 5.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
sentry-ruby (~> 5.19.0)
sentry-ruby (5.19.0)
bigdecimal
Add Sentry to Rails Now we're tracking both JS and Rails errors, phew!
2023-11-06 12:37:40 -08:00
concurrent-ruby (~> 1.0, >= 1.0.2)
Create `rails public_data:commit` task, to share public data dumps I'm starting to port over the functionality that was previously just, me running `yarn db:export:public-data` in `impress-2020` and committing it to Git LFS every time. My immediate motivation is that the `impress-2020` git repository is getting weirdly large?? Idk how these 40MB files have blown up to a solid 16GB of Git LFS data (we don't have THAT many!!!), but I guess there's something about Git LFS's architecture and disk usage that I'm not understanding. So, let's move to a simpler system in which we don't bind the public data to the codebase, but instead just regularly dump it in production and make it available for download. This change adds the `rails public_data:commit` task, which when run in production will make the latest available at `https://impress.openneo.net/public-data/latest.sql.gz`, and will also store a running log of previous dumps, viewable at `https://impress.openneo.net/public-data/`. Things left to do: 1. Create a `rails public_data:pull` task, to download `latest.sql.gz` and import it into the local development database. 2. Set up a cron job to dump this out regularly, idk maybe weekly? That will grow, but not very fast (about 2GB per year), and we can add logic to rotate out old ones if it starts to grow too far. (If we wanted to get really intricate, we could do like, daily for the past week, then weekly for the past 3 months, then monthly for the past year, idk. There must be tools that do this!)
2024-02-29 14:30:33 -08:00
shell (0.8.1)
e2mmap
sync
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
solargraph (0.50.0)
backport (~> 1.2)
benchmark
bundler (~> 2.0)
diff-lcs (~> 1.4)
e2mmap
jaro_winkler (~> 1.5)
kramdown (~> 2.3)
kramdown-parser-gfm (~> 1.1)
parser (~> 3.0)
rbs (~> 2.0)
reverse_markdown (~> 2.0)
rubocop (~> 1.38)
thor (~> 1.0)
tilt (~> 2.0)
yard (~> 0.9, >= 0.9.24)
solargraph-rails (1.1.0)
activesupport
solargraph
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
sprockets (4.2.1)
Update gems to Rails 4.1 (crashes!) Lookin' good on this end, but the server isn't starting up yet, got some fixes to make!
2023-07-29 11:33:39 -07:00
concurrent-ruby (~> 1.0)
Upgrade to latest Sass and Sprockets This required a buncha fixes to how SASS scoping works! Needed to add a bunch of imports for stuff that previously would get read from the global scope by being imported *after* the constants and mixins etc. There's clearly a lot of refactor opportunity here, but I'm not gonna worry about it!!
2023-08-22 16:08:11 -07:00
rack (>= 2.2.4, < 4)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
sprockets-rails (3.5.2)
actionpack (>= 6.1)
activesupport (>= 6.1)
Upgrade to Rails 4.2.11.3 and Ruby 2.4.10 Some tricks required here to get the dependencies to work out, but we got it!! Oh also, we move away from the rbenv in Ubuntu's package manager, because it doesn't support more recent Rubies like 2.4.10.
2023-08-02 15:18:36 -07:00
sprockets (>= 3.0.0)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
stackprof (0.2.26)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
stringio (3.1.1)
Refactor to use OpenID Connect OmniAuth gem instead of plain OAuth2 Right, I didn't totally connect the dots that there's some OpenID features in the mix here for how we expect to identify the user once they authenticate. It requires looking up the provider's public key, and validating the JWT they sent us. This gem does all that for us! I don't actually know what a real NeoPass `id_token` looks like yet? But I'll fill in some placeholder stuff for now, and use that for initializing the account!
2024-03-14 18:11:40 -07:00
swd (2.0.3)
activesupport (>= 3)
attr_required (>= 0.0.5)
faraday (~> 2.0)
faraday-follow_redirects
Create `rails public_data:commit` task, to share public data dumps I'm starting to port over the functionality that was previously just, me running `yarn db:export:public-data` in `impress-2020` and committing it to Git LFS every time. My immediate motivation is that the `impress-2020` git repository is getting weirdly large?? Idk how these 40MB files have blown up to a solid 16GB of Git LFS data (we don't have THAT many!!!), but I guess there's something about Git LFS's architecture and disk usage that I'm not understanding. So, let's move to a simpler system in which we don't bind the public data to the codebase, but instead just regularly dump it in production and make it available for download. This change adds the `rails public_data:commit` task, which when run in production will make the latest available at `https://impress.openneo.net/public-data/latest.sql.gz`, and will also store a running log of previous dumps, viewable at `https://impress.openneo.net/public-data/`. Things left to do: 1. Create a `rails public_data:pull` task, to download `latest.sql.gz` and import it into the local development database. 2. Set up a cron job to dump this out regularly, idk maybe weekly? That will grow, but not very fast (about 2GB per year), and we can add logic to rotate out old ones if it starts to grow too far. (If we wanted to get really intricate, we could do like, daily for the past week, then weekly for the past 3 months, then monthly for the past year, idk. There must be tools that do this!)
2024-02-29 14:30:33 -08:00
sync (0.5.0)
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
temple (0.10.3)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
terser (1.2.3)
Precompile assets when deploying new version I did some refactoring while here too, of pulling the deploy scripts out of `package.json` and into `bin`, to be a bit more canonically Rails-y. (idk how canonical the colon thing is but, probably fine??)
2023-08-19 18:51:46 -07:00
execjs (>= 0.3.0, < 3)
Run `bundle update`
2024-09-26 12:42:18 -07:00
thor (1.3.2)
Move manifest backfill to `swf_assets:manifests` task Okay, I've simplified the migration to *just* add the column, and instead added a task to find assets without manifest URLs and backfill them. Performance is a lot better now, using the `async-http` library, which as I understand it supports both persistent connections when invoked like this, and maybe also HTTP/2 multiplexing?? (Though I'm not actually sure images.neopets.com does lol) I'm not sure about the number of concurrent tasks I picked here, 100 seems okay for an internet thing and for such small requests, but I worry that the CDN is gonna get annoyed or something. Well, we'll see! This task is very resumable if it turns out we get frozen out or something.
2023-11-10 16:52:50 -08:00
thread-local (1.1.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
tilt (2.4.0)
Upgrade to Rails 7.1.3.2 In response to: - https://discuss.rubyonrails.org/t/possible-xss-vulnerability-in-action-controller/84947 - https://discuss.rubyonrails.org/t/possible-redos-vulnerability-in-accept-header-parsing-in-action-dispatch/84946 No evidence that our app has been affected, but I like to move quickly on these!
2024-02-22 11:25:52 -08:00
timeout (0.4.1)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
traces (0.13.1)
Run `bundle update`
2024-09-26 12:42:18 -07:00
turbo-rails (2.0.10)
Add Turbo to speed up the app, and set up for missing UJS features Oh right, we don't have Rails UJS going on anymore, which is what handled the confirmation prompts for deleting lists. Turbo is the more standard modern solution to that, and should speed up certain pageloads, so let's do it! Here I install the `turbo-rails` gem, then run `rails turbo:install` to install the `@hotwired/turbo-rails` npm package. Then I move `application.js` that's run all on pages but the outfit editor into our section of JS that gets run through the bundler, and add Turbo to it. I had to fix a couple tricky things: 1. The outfit editor page doesn't play nice with being swapped into the document, so I make it require a full page reload instead. 2. Prefetching the Sign In link can cause the wrong `return_to` address to be written to the `session`. (It's a GET request that does, ever so slightly, take its own actions, oops!) As a simple hacky answer, we disallow prefetching on that link. Haven't fixed up the UJS stuff for confirm prompts to use Turbo yet, that's next!
2024-03-13 13:43:48 -07:00
actionpack (>= 6.0.0)
railties (>= 6.0.0)
Upgrade to Rails 6.1.7.4 This one was pretty straightforward yaay! Main thing was the change from `render file` to `render template` in a couple places, oh and a thing with complex `order()` clauses.
2023-08-02 17:55:32 -07:00
tzinfo (2.0.6)
concurrent-ruby (~> 1.0)
Run `bundle update`
2024-09-26 12:42:18 -07:00
unicode-display_width (2.6.0)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
uri (0.13.1)
useragent (0.16.10)
Refactor to use OpenID Connect OmniAuth gem instead of plain OAuth2 Right, I didn't totally connect the dots that there's some OpenID features in the mix here for how we expect to identify the user once they authenticate. It requires looking up the provider's public key, and validating the JWT they sent us. This gem does all that for us! I don't actually know what a real NeoPass `id_token` looks like yet? But I'll fill in some placeholder stuff for now, and use that for initializing the account!
2024-03-14 18:11:40 -07:00
validate_url (1.0.15)
activemodel (>= 3.0.0)
public_suffix
Run `bundle update` I also put in a manual bump for `falcon`! The motivation is that I'm working on a Ruby 3.3.0 upgrade in another branch, and I'm getting deprecation warnings from the `async` gem, which I think are resolved in the latest version, so I figure, hey, good time for an update!
2024-02-22 11:48:32 -08:00
warden (1.2.9)
rack (>= 2.0.9)
Security updates Resolves CVE-2023-40175 and CVE-2023-38037.
2023-10-23 19:08:56 -07:00
web-console (4.2.1)
Add web console support for Vagrant users
2023-08-02 17:36:32 -07:00
actionview (>= 6.0.0)
activemodel (>= 6.0.0)
Upgrade web-console Huh, error pages weren't actually working on this older version of web-console, but now they are! Solution found here: https://discuss.rubyonrails.org/t/question-dev-mode-500-errors-not-displayed-config-consider-all-requests-local-not-honored/78453/7
2023-08-02 16:20:50 -07:00
bindex (>= 0.4.0)
Add web console support for Vagrant users
2023-08-02 17:36:32 -07:00
railties (>= 6.0.0)
Refactor to use OpenID Connect OmniAuth gem instead of plain OAuth2 Right, I didn't totally connect the dots that there's some OpenID features in the mix here for how we expect to identify the user once they authenticate. It requires looking up the provider's public key, and validating the JWT they sent us. This gem does all that for us! I don't actually know what a real NeoPass `id_token` looks like yet? But I'll fill in some placeholder stuff for now, and use that for initializing the account!
2024-03-14 18:11:40 -07:00
webfinger (2.1.3)
activesupport
faraday (~> 2.0)
faraday-follow_redirects
Run `bundle update`
2024-09-26 12:42:18 -07:00
webrick (1.8.2)
Upgrade to Rails 5.2.8.1 Some important little upgrades but mostly straightforward! Note that there's still a known issue where item searches crash, I was hoping that this was a bug in Rails 4.2 that would be fixed on upgading to 5, but nope, oh well! Also uhh I just got a bit silly and didn't actually mean to go all the way to 5.2 in one go, I had meant to start at 5.0… but tbh the 5.1 and 5.2 changes seem small, and this seems to be working, so. Yeah ok let's roll!
2023-08-02 16:05:02 -07:00
websocket-driver (0.7.6)
websocket-extensions (>= 0.1.0)
websocket-extensions (0.1.5)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
will_paginate (4.0.1)
Run `bundle update`
2024-09-26 12:42:18 -07:00
yard (0.9.37)
zeitwerk (2.6.18)
upgrade to rails 3, make item tests pass
2010-10-03 16:49:33 -07:00
PLATFORMS
ruby
DEPENDENCIES
move to unstable rocketamf so that it builds hashes from registries, not arrays
2011-01-13 14:22:07 -08:00
RocketAMF!
Add Owls values to the item page Eyy it's time!! Long-requested, finally here lol
2023-11-03 16:20:02 -07:00
addressable (~> 2.8)
Upgrade async and related gems, and fix async-http response handling When playing with a Rainbow Pool syncing task, I noticed that error handling wasn't working correctly for requests using `async-http`: if the block raised an error, the `Sync` block would never return. My suspicion is that this is because we were never reading or releasing the request body. In this change, I upgrade all the relevant gems for good measure, and switch to using the response object yielded by the _block_, so we can know it's being resource-managed correctly. Now, failures raise errors as expected! (I tested all these relevant service calls, too!)
2024-09-07 12:14:12 -07:00
async (~> 2.17)
async-http (~> 0.75.0)
Update all our gems as far as we can Got pretty far, there's a couple still held back by Rails 6+, but yeah doing great!
2023-08-02 17:16:24 -07:00
bootsnap (~> 1.16)
Upgrade to Rails 4.2.11.3 and Ruby 2.4.10 Some tricks required here to get the dependencies to work out, but we got it!! Oh also, we move away from the rbenv in Ubuntu's package manager, because it doesn't support more recent Rubies like 2.4.10.
2023-08-02 15:18:36 -07:00
devise (~> 4.9, >= 4.9.2)
Can log into OpenNeo ID accounts directly! A lot of rough edges here (e.g. no styles on the flash messages), but it's working and that's good!! I tested this by temporarily switching to the production database and logging in as matchu! Still missing a lot of big features too, like registration, password resets, settings page, etc.
2023-08-06 15:52:05 -07:00
devise-encryptable (~> 0.2.0)
Remove dotenv-deployment, upgrade dotenv-rails Idk exactly what's going on with dotenv-deployment, if it turns out it was critical to our deploy process then we'll change the deploy process! It's deprecated and conflicts with gem deps for `dotenv-rails`.
2023-08-02 13:41:37 -07:00
dotenv-rails (~> 2.8, >= 2.8.1)
Upgrade async and related gems, and fix async-http response handling When playing with a Rainbow Pool syncing task, I noticed that error handling wasn't working correctly for requests using `async-http`: if the block raised an error, the `Sync` block would never return. My suspicion is that this is because we were never reading or releasing the request body. In this change, I upgrade all the relevant gems for good measure, and switch to using the response object yielded by the _block_, so we can know it's being resource-managed correctly. Now, failures raise errors as expected! (I tested all these relevant service calls, too!)
2024-09-07 12:14:12 -07:00
falcon (~> 0.48.0)
Upgrade haml I was hoping this would fix a character encoding bug, it didn't really? but it doesn't seem to hurt and is probably good to do
2023-07-22 12:58:15 -07:00
haml (~> 6.1, >= 6.1.1)
Version the http_accept_languages gem idk why we were pulling from git before, probably to get a feature that wasn't pushed to rubygems yet? But now the latest rubygems version matches the latest repo commit (both back in 2017 lol), so let's do that for greater stability and clarity!
2023-08-02 13:24:56 -07:00
http_accept_language (~> 2.1, >= 2.1.1)
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
httparty (~> 0.22.0)
Bundle wardrobe-2020 into the app We add jsbuilding-rails to get esbuild running in the app, and then we copy-paste the files we need from impress-2020 into here! I stopped at the point where it was building successfully, but it's not running correctly: it's not sure about `process.env` in `next`, and I think the right next step is to delete the NextJS deps altogether and use React Router instead.
2023-08-10 15:56:36 -07:00
jsbundling-rails (~> 1.1)
Update all our gems as far as we can Got pretty far, there's a couple still held back by Rails 6+, but yeah doing great!
2023-08-02 17:16:24 -07:00
letter_opener (~> 1.8, >= 1.8.1)
Add mini profiler to each page It shows up in development always, and if you're logged in as Me Specifically in production! I'm using this to poke at memory usage for pages that seem suspicious. I don't know why our app reliably grows so large in RAM, but my hunch is that maybe there are some pages that just use a truly large amount to begin with - and I've learned Ruby doesn't release memory back after it's GC'd, it just grows the process and keeps the free space to itself in its own heap! So I'm just eyeing pages that I know *can* have a lot going on, and seeing what I find!
2023-10-27 19:38:49 -07:00
memory_profiler (~> 1.0)
Upgrade to Rails 5.2.8.1 Some important little upgrades but mostly straightforward! Note that there's still a known issue where item searches crash, I was hoping that this was a bug in Rails 4.2 that would be fixed on upgading to 5, but nope, oh well! Also uhh I just got a bit silly and didn't actually mean to go all the way to 5.2 in one go, I had meant to start at 5.0… but tbh the 5.1 and 5.2 changes seem small, and this seems to be working, so. Yeah ok let's roll!
2023-08-02 16:05:02 -07:00
mysql2 (~> 0.5.5)
Upgrade to webrick 1.8 Literally don't know why this wasn't 1.8 when I first installed it? Whatever!
2023-08-03 16:43:37 -07:00
nokogiri (~> 1.15, >= 1.15.3)
Add OmniAuth plugin to AuthUser This is setting us up for NeoPass, but first we're just gonna try stuff with the "developer" strategy that's built in for testing, rather than using the NeoPass dev server!
2024-03-13 13:10:59 -07:00
omniauth (~> 2.1)
omniauth-rails_csrf_protection (~> 1.0)
Refactor to use OpenID Connect OmniAuth gem instead of plain OAuth2 Right, I didn't totally connect the dots that there's some OpenID features in the mix here for how we expect to identify the user once they authenticate. It requires looking up the provider's public key, and validating the JWT they sent us. This gem does all that for us! I don't actually know what a real NeoPass `id_token` looks like yet? But I'll fill in some placeholder stuff for now, and use that for initializing the account!
2024-03-14 18:11:40 -07:00
omniauth_openid_connect (~> 0.7.1)
Update all our gems as far as we can Got pretty far, there's a couple still held back by Rails 6+, but yeah doing great!
2023-08-02 17:16:24 -07:00
parallel (~> 1.23)
rack-attack (~> 6.7)
Add mini profiler to each page It shows up in development always, and if you're logged in as Me Specifically in production! I'm using this to poke at memory usage for pages that seem suspicious. I don't know why our app reliably grows so large in RAM, but my hunch is that maybe there are some pages that just use a truly large amount to begin with - and I've learned Ruby doesn't release memory back after it's GC'd, it just grows the process and keeps the free space to itself in its own heap! So I'm just eyeing pages that I know *can* have a lot going on, and seeing what I find!
2023-10-27 19:38:49 -07:00
rack-mini-profiler (~> 3.1)
Upgrade to Rails 7.2.1 No pressing reason, I'm just doing upgrades today, and noticed a new version is out, and scrolled the patch notes and there's no obvious breaking changes for my purposes, so. Up we go!
2024-09-20 12:57:55 -07:00
rails (~> 7.2, >= 7.2.1)
Upgrade to Rails 6.0.6.1 Another pretty easy one! We have the `rails app:update` changes in here too.
2023-08-02 17:27:11 -07:00
rails-i18n (~> 7.0, >= 7.0.7)
Update all our gems as far as we can Got pretty far, there's a couple still held back by Rails 6+, but yeah doing great!
2023-08-02 17:16:24 -07:00
rdiscount (~> 2.2, >= 2.2.7.1)
Upgrade to Ruby 2.2.4, Rails 4.0.13 NOTE: This doesn't boot yet! There's something changed in the `devise` API that we'll need to fix! ``` /vagrant/config/initializers/devise.rb:46:in `block in <top (required)>': undefined method `encryptor=' for Devise:Module (NoMethodError) ``` But yeah, we navigated the gem upgrades, and also I ran `rake rails:update` and hand-processed the suggestions it had for our config files.
2023-07-21 19:39:32 -07:00
react-rails (~> 2.7, >= 2.7.1)
Update all our gems as far as we can Got pretty far, there's a couple still held back by Rails 6+, but yeah doing great!
2023-08-02 17:16:24 -07:00
sanitize (~> 6.0, >= 6.0.2)
Upgrade to latest Sass and Sprockets This required a buncha fixes to how SASS scoping works! Needed to add a bunch of imports for stuff that previously would get read from the global scope by being imported *after* the constants and mixins etc. There's clearly a lot of refactor opportunity here, but I'm not gonna worry about it!!
2023-08-22 16:08:11 -07:00
sass-rails (~> 6.0)
Add Sentry to Rails Now we're tracking both JS and Rails errors, phew!
2023-11-06 12:37:40 -08:00
sentry-rails (~> 5.12)
sentry-ruby (~> 5.12)
Create `rails public_data:commit` task, to share public data dumps I'm starting to port over the functionality that was previously just, me running `yarn db:export:public-data` in `impress-2020` and committing it to Git LFS every time. My immediate motivation is that the `impress-2020` git repository is getting weirdly large?? Idk how these 40MB files have blown up to a solid 16GB of Git LFS data (we don't have THAT many!!!), but I guess there's something about Git LFS's architecture and disk usage that I'm not understanding. So, let's move to a simpler system in which we don't bind the public data to the codebase, but instead just regularly dump it in production and make it available for download. This change adds the `rails public_data:commit` task, which when run in production will make the latest available at `https://impress.openneo.net/public-data/latest.sql.gz`, and will also store a running log of previous dumps, viewable at `https://impress.openneo.net/public-data/`. Things left to do: 1. Create a `rails public_data:pull` task, to download `latest.sql.gz` and import it into the local development database. 2. Set up a cron job to dump this out regularly, idk maybe weekly? That will grow, but not very fast (about 2GB per year), and we can add logic to rotate out old ones if it starts to grow too far. (If we wanted to get really intricate, we could do like, daily for the past week, then weekly for the past 3 months, then monthly for the past year, idk. There must be tools that do this!)
2024-02-29 14:30:33 -08:00
shell (~> 0.8.1)
Add Solargraph autocomplete while in development This is a Ruby language server that integrates with my editor! Static analysis of Ruby and Rails is pretty tricky, but it's working and I think that's neat!!
2024-07-01 15:35:39 -07:00
solargraph (~> 0.50.0)
solargraph-rails (~> 1.1)
Upgrade to latest Sass and Sprockets This required a buncha fixes to how SASS scoping works! Needed to add a bunch of imports for stuff that previously would get read from the global scope by being imported *after* the constants and mixins etc. There's clearly a lot of refactor opportunity here, but I'm not gonna worry about it!!
2023-08-22 16:08:11 -07:00
sprockets (~> 4.2)
Add mini profiler to each page It shows up in development always, and if you're logged in as Me Specifically in production! I'm using this to poke at memory usage for pages that seem suspicious. I don't know why our app reliably grows so large in RAM, but my hunch is that maybe there are some pages that just use a truly large amount to begin with - and I've learned Ruby doesn't release memory back after it's GC'd, it just grows the process and keeps the free space to itself in its own heap! So I'm just eyeing pages that I know *can* have a lot going on, and seeing what I find!
2023-10-27 19:38:49 -07:00
stackprof (~> 0.2.25)
Precompile assets when deploying new version I did some refactoring while here too, of pulling the deploy scripts out of `package.json` and into `bin`, to be a bit more canonically Rails-y. (idk how canonical the colon thing is but, probably fine??)
2023-08-19 18:51:46 -07:00
terser (~> 1.1, >= 1.1.17)
Move manifest backfill to `swf_assets:manifests` task Okay, I've simplified the migration to *just* add the column, and instead added a task to find assets without manifest URLs and backfill them. Performance is a lot better now, using the `async-http` library, which as I understand it supports both persistent connections when invoked like this, and maybe also HTTP/2 multiplexing?? (Though I'm not actually sure images.neopets.com does lol) I'm not sure about the number of concurrent tasks I picked here, 100 seems okay for an internet thing and for such small requests, but I worry that the CDN is gonna get annoyed or something. Well, we'll see! This task is very resumable if it turns out we get frozen out or something.
2023-11-10 16:52:50 -08:00
thread-local (~> 1.1)
Add Turbo to speed up the app, and set up for missing UJS features Oh right, we don't have Rails UJS going on anymore, which is what handled the confirmation prompts for deleting lists. Turbo is the more standard modern solution to that, and should speed up certain pageloads, so let's do it! Here I install the `turbo-rails` gem, then run `rails turbo:install` to install the `@hotwired/turbo-rails` npm package. Then I move `application.js` that's run all on pages but the outfit editor into our section of JS that gets run through the bundler, and add Turbo to it. I had to fix a couple tricky things: 1. The outfit editor page doesn't play nice with being swapped into the document, so I make it require a full page reload instead. 2. Prefetching the Sign In link can cause the wrong `return_to` address to be written to the `session`. (It's a GET request that does, ever so slightly, take its own actions, oops!) As a simple hacky answer, we disallow prefetching on that link. Haven't fixed up the UJS stuff for confirm prompts to use Turbo yet, that's next!
2024-03-13 13:43:48 -07:00
turbo-rails (~> 2.0)
Add web console support for Vagrant users
2023-08-02 17:36:32 -07:00
web-console (~> 4.2)
Upgrade to Rails 5.2.8.1 Some important little upgrades but mostly straightforward! Note that there's still a known issue where item searches crash, I was hoping that this was a bug in Rails 4.2 that would be fixed on upgading to 5, but nope, oh well! Also uhh I just got a bit silly and didn't actually mean to go all the way to 5.2 in one go, I had meant to start at 5.0… but tbh the 5.1 and 5.2 changes seem small, and this seems to be working, so. Yeah ok let's roll!
2023-08-02 16:05:02 -07:00
will_paginate (~> 4.0)
improve app infrastructure to make a dev environment easier to reproduce This commit will require a few changes to the deployment process: * store AWS credentials in AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY env vars * store OpenNeo Auth credentials in OPENNEO_AUTH_APP, OPENNEO_AUTH_SERVER, and OPENNEO_AUTH_SECRET env vars STRIPE_SECRET_KEY and STRIPE_PUBLISHABLE_KEY are now required, too; better have a good .env. You can always put in dummy values if you have no credentials, though; they only get called up if there's a transaction. SECRET_TOKEN is now an env var, too, but the production deploy process currently replaces config/initializers/secret_token.rb anyway; this might be the way to go later, though.
2015-07-16 14:44:52 -07:00
Upgrade to Ruby 2.2.4, Rails 4.0.13 NOTE: This doesn't boot yet! There's something changed in the `devise` API that we'll need to fix! ``` /vagrant/config/initializers/devise.rb:46:in `block in <top (required)>': undefined method `encryptor=' for Devise:Module (NoMethodError) ``` But yeah, we navigated the gem upgrades, and also I ran `rake rails:update` and hand-processed the suggestions it had for our config files.
2023-07-21 19:39:32 -07:00
RUBY VERSION
Upgrade to Rails 7.2.1 No pressing reason, I'm just doing upgrades today, and noticed a new version is out, and scrolled the patch notes and there's no obvious breaking changes for my purposes, so. Up we go!
2024-09-20 12:57:55 -07:00
ruby 3.3.5p100
Upgrade to Ruby 2.2.4, Rails 4.0.13 NOTE: This doesn't boot yet! There's something changed in the `devise` API that we'll need to fix! ``` /vagrant/config/initializers/devise.rb:46:in `block in <top (required)>': undefined method `encryptor=' for Devise:Module (NoMethodError) ``` But yeah, we navigated the gem upgrades, and also I ran `rake rails:update` and hand-processed the suggestions it had for our config files.
2023-07-21 19:39:32 -07:00
improve app infrastructure to make a dev environment easier to reproduce This commit will require a few changes to the deployment process: * store AWS credentials in AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY env vars * store OpenNeo Auth credentials in OPENNEO_AUTH_APP, OPENNEO_AUTH_SERVER, and OPENNEO_AUTH_SECRET env vars STRIPE_SECRET_KEY and STRIPE_PUBLISHABLE_KEY are now required, too; better have a good .env. You can always put in dummy values if you have no credentials, though; they only get called up if there's a transaction. SECRET_TOKEN is now an env var, too, but the production deploy process currently replaces config/initializers/secret_token.rb anyway; this might be the way to go later, though.
2015-07-16 14:44:52 -07:00
BUNDLED WITH
Update Ruby to 3.3.4, and update gems For the gems, I mostly just ran `bundle update`; with the exception of `httparty`, because latest Ruby throws a deprecation warning about its use of the deprecated `csv` stdlib, which the latest version resolves. One other little thing: this is on my new Fedora workstation, and I had to deal with a known bug where the `sassc` gem compiles a `libsass.so` file, but saves it in the wrong place somehow. Here's the known bug, and the comment that helped me: https://github.com/sass/sassc-ruby/issues/146#issuecomment-2028974524 And here's what I ran to get it into the right place: ```shell ln -s ~/.local/share/gem/ruby/3.3.0/extensions/aarch64-linux/3.3.0/sassc-2.4.0/sassc/libsass.so \ ~/.local/share/gem/ruby/3.3.0/gems/sassc-2.4.0/lib/sassc/libsass.so ``` This thing about `libsass` isn't reflected in the code changes anywhere in this commit! I'm just mentioning it so that it's literally written down anywhere. (I did try other comments' advice to use an older version of `sassc` first, but I ran into compilation errors, so figured this machine-side hack was better than untangling that mess.)
2024-08-27 17:06:22 -07:00
2.5.18
Copy permalink