Sprockets/sass/compass/rails compatibility issues

[jaroslawr]

It seems for a good while now it has been very hard to get rails+sprockets+sass+compass to work sensibly, due to serious bugs cross cutting across the various projects. Even now I don't see any way at all to configure the gems on Rails 4.2 to not get either a Gem version requirements conflict, or the "can't dump anonymous class" issue that slows down page rendering down to a crawl, or the "stylesheet_link_tag: wrong number of arguments (2 for 1)" issue or some still other serious bug. While I of course appreciate the free-of-charge work that everyone is putting into the projects and the ability to use it at all, this has been a major maintenance issue and time-sink for me.

It would be nice to have some note in the README on version combinations that sensibly work together and a note on if and when (in the sense of at least "when sprockets reaches 3.0 and compass 2.0") one can possibly expect sprockets+sass+compass to work fully reliably with Rails 4.2. Maybe also a small test suite for all the four projects together could be created to ensure the gems evolve in a coherent manner, although I do realize it's a coordination problem as much as anything else.

[josh]

Hey @jaroslawr,

We've been working to get things straighten out on the compass end. While that library still monkey patches the entire stack (which causes all sorts of instability), its at least tested a little better now. I don't think a new version of compass-rails has been cut, but I'd give https://github.com/Compass/compass-rails master a try again.

[jaroslawr]

@josh I am giving it a try every day for a few weeks now ;), and I reported one issue in compass that was fixed so it's not that I am just complaining, but compass-rails master still works only with sprockets 2.12, which causes the "can't dump anonymous class" warning and slows down the initial page load from 3 seconds to something like 2 minutes. It would be nice to at least have some well visible notice of those issues until they are somehow resolved, I am sure lots of people are wasting lots of time on this, and I personally spent some hours already jumping between the different closed issue reports and trying to figure out whether ultimately a proper fix exists or not and it seems so far it does not exist. I think an issue like the one I opened should perhaps remain open on all the related projects until you can finally just type:

gem 'rails'
gem 'sass-rails'
gem 'sprockets-rails'
gem 'compass-rails'

and have a working setup. I mean it is indeed an issue that people are wasting time on it and they might not necessarily know whether it's an issue with sprockets, sass, compass or rails.

[jaroslawr]

I mean, for heavens sake:

sass/sass#1028
sass/sass#1162
sstephenson/sprockets#507
sstephenson/sprockets#540
http://stackoverflow.com/questions/23331172/rails-4-wrong-number-of-arguments-2-for-1-stylesheet-link-tag-and-javascri
http://www.stefanwienert.de/blog/2014/04/01/fixing-annoying-asset-slash-compass-slash-sass-error-after-rails-4-dot-0-4-upgrade/ (last comment from 10 days ago)
http://stackoverflow.com/questions/26416065/which-gem-is-breaking-rails-application-css-scss-wrong-number-of-arguments-3-for

I still don't see a way to get rid of those issues on Rails 4.2. The only fully working setup is on Rails 4.0/4.1 with all the gems fixed on older versions.

[jaroslawr]

@josh That all the issues are closed and locked despite no clear fix is not super nice towards people either - basically I think there is a major problem in how this issue is being handled on the "communication with users" side. I understand you guys are all putting a lot of work towards fixing this, but a short note in the README or a clear collective open issue would save everyone a lot of time and nerves.

[matthewd]

@jaroslawr this is barely any more a sprockets-rails issue than it is a ruby issue: compass-rails is strictly downstream. There is nothing that sprockets-rails can do about it, and therefore there is no benefit to an open issue.

This project's issue tracker is not a suitable venue for a list of known issues with downstream projects, and I don't think the README is either.

[jaroslawr]

@matthewd The point is to have some conclusive summary information in a place that is easily visible to people who encounter the issues and look for a solution. That the "issue tracker is not a suitable venue..." is just a statement of opinion, the issue tracker is what you guys decide it to be. Typically people in search for a solution to this arrive at the issue tracker of one of the projects listed, and hence the issue tracker is, in my opinion, very much the right place to do it. It's not just a compass-rails issue either I guess, one of the compatibility issues I speak about was in fact closed in the sass tracker as supposedly a sprockets issue:

sass/sass#1028

You can save lots of people lots of time by just having a cross-referenced open issue, and this is very much a big real benefit for everyone (including project maintainers) for not a lot of cost. Once the issue is gone, you can close the issue, what's the big deal about that, what grand principles of issue tracking prohibit that?

The point is: people will likely anyway continue to open the issues because they experience problems and have no clue which projects they ultimately originate from. I personally would prefer to have one open issue where the overall current picture is communicated clearly and where people can discuss rather than having to close 20 different issue reports on the same thing in a row. Just look around the web for how many compatibility problems of this kind are being reported in various places. Closing everything down and locking down, saying that "it's another guys job", while the other guy says "it's @matthewd's job" does not help anyone, I mean even if one of you is really right it does not even help you not get nagged about this again. It's not the first time those kind of issues arise either, and I just think some improvements to the policy of handling them could be made, even if just in how they are communicated.

[matthewd]

That "one of the issues" is from a previous problem, and over a year old. That alone shows why we can't keep some generic "there might be problems that are out of our control" issue open: people will lump together any misbehaviour they encounter and add useless "any fix yet?!!" comments.. with a set of closely-interacting libraries, there will always be some circumstance under which they can't be made to cooperate.

Being ping-ponged between projects is certainly frustrating, and if there's disagreement/confusion between maintainers of large/popular projects, then closer attention can be warranted to get everyone on the same page. But I haven't seen anyone claim that the current issue isn't on the compass-rails side.

the issue tracker is what you guys decide it to be

For something that you've stated as a premise, you don't seem to agree.

The issue tracker on this project (and all rails projects) is for tracking things that the maintainers need to do something about. The (Rails) mailing list, IRC, and Stack Overflow are the designated support forums.

[jaroslawr]

@matthewd Well, I don't where the current issue is, because there does not seem to be a place where one can find a summary of the current state of the matter, and that's precisely my whole point. That's why I opened up a cross-referenced issue, but the discussion ultimately has to happen in some single place, it's a pity you scuttle it before people have the chance to contribute their voices, and it probably explains a bit about how things got to the place where they are in the first place.

The issue in the sass tracker might be a year old, but there is a reason it kept being bumped until the issue was locked - as far as I understand the fix made it only into sprockets 3 and compass-rails currently does not work with sprockets 3 at all. It is highly questionable whether a regression in sprockets the fix for which was not backported is really purely an issue of compass. It would also seem plausible maintainers might "need" (or rather be willing to if they care about their users) to do something about an issue that causes lots of people to waste hours of work on nothing.

Obviously nobody can force you to change the way you run your issue tracker, to me it simply seems the way you are handling it in this particular case causes nerves and extra work both to you and to your users.

[jaroslawr]

One correction: actually it seems the issue I am seeing on Rails 4.2 is not:
sass/sass#1028

But a new similar issue:
Compass/compass-rails#219

If it really all boils down to compass, I think it would be nice for compass-rails to either straighten out the gem dependencies or to put some note in the readme how to configure the gem correctly for each major Rails version. As said, not being heavily involved in all the three projects I can hardly know up front where precisely the issues ultimately lie, the fact is that depending on the Rails version you happen to use you have to spend hours and hours to look for the right version incantations for the Gemfile. I was hoping to discuss this simply in any one of the three related issue trackers to get an agreement from all the people involved on some fix whereever it makes the most sense.

[rafaelfranca]

We would love to help compass-rails people to get it working with the current set of sprockets, sprockets-rails and sass-rails but I do not agree to keep any issue open on these issue tracker.

Unless there are problems in applications that are not using compass-rails, these are not sprockets, sprockets-rails or sass-rails issues. These are incompatibility problems at compass-rails and should be handled in its issue tracker. So yeah, lets focus the discussion at Compass/compass-rails#218