You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 25, 2021. It is now read-only.
I'd love to package the turbolinks for Fedora, but the way how the assets are split into separate gem makes the whole matter quite unfortunate. Let me explain.
turbolinks is now independent js/coffee script library. So I should take it and package as js-turbolinks package. There is the turbolinks gem, i.e. this library. I should package it as rubygem-turbolinks in Fedora. Up until here, everything looks OK.
However, you split the JS assets into independent turbolinks-source gem and here it becomes interesting. Historically, for various reasons, we tried to unbundle everything in Fedora, that means that the turbolinks-source should depend on js-turbolinks and the .js library should by just filesystem system symlink. But, the thing is that in theory, the js-turbolinks might be of different version then the rubygem-turbolinks-source. That in turn means, that the version which is reported by turbolinks-source might not match the version of actual turbolinks.js. I might fix it by very strict version dependencies, but that has disadvantages as well, e.g:
we have to always update js-turbolinks together with rubygem-turbolink-source,
somebody might decide to update one library, but the other library can't be updated due to other version restrictions.
In this case, our live would be much easier, if the actual asset files were included directly into turbolinks. I see almost no disadvantages on your side, while it would make our life much easier.
Just FTR, I have been previously in the similar position with therubyracer gem, which used to bundled v8. This was unfortunate (because it is bundling) but we could unbundle the v8 and move on. Once the libv8 was introduced as dependency of therubyracer, we could not really move on with update.
I'd be very grateful if you can discontinue the turbolinks-source. Thanks for considering this 'weird' request.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'd love to package the turbolinks for Fedora, but the way how the assets are split into separate gem makes the whole matter quite unfortunate. Let me explain.
turbolinks is now independent js/coffee script library. So I should take it and package as js-turbolinks package. There is the turbolinks gem, i.e. this library. I should package it as rubygem-turbolinks in Fedora. Up until here, everything looks OK.
However, you split the JS assets into independent turbolinks-source gem and here it becomes interesting. Historically, for various reasons, we tried to unbundle everything in Fedora, that means that the turbolinks-source should depend on js-turbolinks and the .js library should by just filesystem system symlink. But, the thing is that in theory, the js-turbolinks might be of different version then the rubygem-turbolinks-source. That in turn means, that the version which is reported by turbolinks-source might not match the version of actual turbolinks.js. I might fix it by very strict version dependencies, but that has disadvantages as well, e.g:
In this case, our live would be much easier, if the actual asset files were included directly into turbolinks. I see almost no disadvantages on your side, while it would make our life much easier.
Just FTR, I have been previously in the similar position with therubyracer gem, which used to bundled v8. This was unfortunate (because it is bundling) but we could unbundle the v8 and move on. Once the libv8 was introduced as dependency of therubyracer, we could not really move on with update.
I'd be very grateful if you can discontinue the turbolinks-source. Thanks for considering this 'weird' request.
The text was updated successfully, but these errors were encountered: