Open qwertfisch opened 2 months ago
I'm hitting the exact same issue with a very similar install process. Although there are a few differences:
None of those should make any material difference (if anything they rule out some possible issues).
I've retried a number of times and it's constantly reproducible.
I've checked and/or tested everything I could find online that seemed relevant and no joy.
However, on one occasion mucking around with updating dependencies I did get past the "Sprockets::FileNotFound: couldn't find file 'bootstrap-sprockets'" and it seemed to be ok (although I didn't actually test the UI in a browser).
Unfortunately I'm not 100% what I did to "fix" it. I did take notes of what I did (reinstalled bootstrap-sass
) but retesting it there must have been something I did that I didn't note as I got the same issue again. :cry:
I did notice that there have been a few commits to master (https://github.com/TracksApp/tracks/compare/v2.7.1...master) but none of them seem relevant (although perhaps worth testing just in case?).
I'll try again sometime soon, but I've already spent too much time on this and need to move on...
I'll post back if/when I find a fix and I'd love it if you (or anyone else) did the same. :grin:
I'm not sure if it's at all relevant, but I neglected to mention that I have both Nodejs and yarn preinstalled. Node v18.x is installed from Debian apt repo and yarn v1.22.x installed via upstream apt repo.
Hi guys, i've had the same issue, at the same environment (Debian 12, tracks 2.7.1, nodejs from nodesource repo and yarn from their deb repo), but now managed to "fix" it. "fix" because my ruby on rails knowledge is more than a decade old and never refreshed. Looking at the error, i thought that the file in question (bootstrap-sprockets.js) was installed, but not in the "search path" for files rake were looking for them. Eventually i've found this answer on stackoverflow:
gem 'bootstrap-sass' must be on production group too.
So i modified the Gemfile, putting bootstrap-sass not only in the :assets group, but also above (where i think the "production" group resides, implicitly. (remember: i hadn't contact with rails since more than a decade ;-)):
tracks@v31281:~/tracks$ git diff Gemfile
diff --git a/Gemfile b/Gemfile
index 02189990..459fd657 100644
--- a/Gemfile
+++ b/Gemfile
@@ -8,6 +8,7 @@ gem 'rails', '~> 6.1'
gem 'font-awesome-sass', '~> 6.5.2'
gem 'jquery-rails', '~> 4.6'
gem 'jquery-ui-rails', '~>7.0.0'
+gem 'bootstrap-sass', '3.4.1'
gem 'aasm', '~> 5.5.0'
gem 'acts_as_list'
gem 'bcrypt', '~> 3.1.20'
Eh tada! Afterwards the precompilation of assets worked fine, and now i'm happily running the latest tracks version :-)
Hope this helps for you, too.
cheers Hans-Jürgen
Thanks @hbeck001! You're a legend! I'll give it a go and post back.
Wonderful, that solved the issue! It was just this line.
The Gemfile
should be changed, but I do not know enough to be sure that doesn’t create any bugs in another configuration …
By the way: the final step, starting Rails, also does not work as stated in the manual. Executing bundle exec rails server
always assumes I want to use the “new” function, even if executing Rails without any parameters. To execute the “server” function, I called the binary directly:
RAILS_SERVE_STATIC_FILES=TRUE bin/rails server -e production
@hbeck001 - I can also confirm that your change in the Gemfile
works. But I believe I've found the "proper fix". I've also found another workaround that I think is "cleaner" and I will use in the meantime.
@qwertfisch - I'm running Tracks via Passenger, but I wonder if either the "fix" or the workaround I note below also "fix" the requirement you hit when running via the rails server? [update] looks like I misunderstood the context and this comment can be ignored.
There is a TL;DR of my conclusion at the bottom for those in a rush, but here's my experience and rational for my conclusion - in "ADHD stream of consciousness" style.. :grin:
After adding gem 'bootstrap-sass', '3.4.1'
near the top of the Gemfile
and running bundle install
I get this message:
Your Gemfile lists the gem bootstrap-sass (= 3.4.1) more than once.
You should probably keep only one of them.
Remove any duplicate entries and specify the gem only once.
While it's not a problem now, it could cause errors if you change the version of one of them later.
Removing the other bootstrap-sass
(in assets
section) from the Gemfile
"fixes" that message.
But why?
Why is this an issue in the first place and why does adding or moving bootstrap-sass
fix it?
I've had (very) limited experience with RoR but I hate needing to do some hacky feeling workaround that I don't understand...
After some hunting, I discovered that the assets
section in the Gemfile
was (should have been) removed when using Rails v4.0+. From the v3.2 -> v4.0 upgrade guide:
Rails 4.0 removed the assets group from Gemfile. You'd need to remove that line from your Gemfile when upgrading.
Digging further I found the commit and rational for that change.
I can confirm that removing the assets
section altogether and retabbing the gems inside it is another alternative ("proper"?) fix. I.e.:
diff --git a/Gemfile b/Gemfile
index 6cb7fada..af380894 100644
--- a/Gemfile
+++ b/Gemfile
@@ -28,14 +28,12 @@ gem 'pg', '~> 1.1', group: :postgresql
# See https://github.com/sstephenson/execjs#readme for more supported runtimes
gem 'mini_racer', group: :therubyracer
-group :assets do
- gem 'coffee-rails', '~> 5.0.0'
- gem 'sassc-rails', '~> 2.1.2'
- gem 'bootstrap-sass', '3.4.1'
- gem 'uglifier', '>=1.3.0'
- gem 'listen'
- gem 'tolk', '~> 5.0.1'
-end
+gem 'coffee-rails', '~> 5.0.0'
+gem 'sassc-rails', '~> 2.1.2'
+gem 'bootstrap-sass', '3.4.1'
+gem 'uglifier', '>=1.3.0'
+gem 'listen'
+gem 'tolk', '~> 5.0.1'
group :development, :optional => true do
gem 'spring', '~> 4'
I read through some of the discussion on that Rails commit and it seems that at the time it was somewhat contentious and reading through I found another workaround for this precomplie issue:
[...] keep the assets group in my Rails 4 apps and precompile in production
RAILS_ENV=production RAILS_GROUPS=assets bundle exec rake assets:precompile
I can confirm that that also works. IMO it feels like a "cleaner" install workaround (than manually editing the Gemfile
.
TL;DR IMO the "proper" fix for this issue is to remove the assets
section from the Gemfile
.
I'll open a PR to apply that change and see what @ZeiP thinks. In the meantime, I'll workaround this issue by setting RAILS_GROUPS=assets
when pre-compling assets...
Sorry for not being able to get back to this sooner! The problem can indeed be fixed by moving stuff around from the assets group; the group is there because the Docker build process uses it as to not include any extra dependencies in the final image. But as the assets group is not optional it should IMO be pulled with the current instructions... Weird.
I was attempting to install the latest release 2.7.1, using the custom server installation path. I a using Ruby 3.2.0 with a MySQL database and a recent bundler. (In fact it is too new, so that the
bundle install
first installs the older version 2.4.1.)I followed the steps successfully with downloading Tracks, setting the configuration to MySQL and then populate the database using the listed command:
bundle exec rake db:migrate RAILS_ENV=production
The installation steps work until here. The next command to precompile the assets unfortunately fails.
I am not skilled in Ruby nor Rails, so I was not able to google and understand possible solutions by removing some dependencies or requirements. There are too many different languages and configuration files at work, so I cannot say what the error really means here.
The error message further reports where it looked for the missing file, followed by a call stack, which I omitted for now (if it is useful, please ask). The error originates here.
I replaced my username with a generic
username
in the paste output. All commands were executed in/var/www/virtual/username/apps/tracks/
where the Tracks installation is located. Its contents are from the release archive.