Resources destination
Closed this issue · 7 comments
Hello. I used to provide path to resources through ./ paths and surprisingly found that on greasyfork it doesn't work.
IMHO greasyfork should parse metadata block and download or make way to provide all the dependent files through ./ path.
1 If the data is imported from remote location it should download it.
2 Otherwise for each ./ path greasyfork should create a form allowing to upload additional file.
Greasy Fork is not here to host the images or whatever your script uses. Use a full URL and host them somewhere else.
Greasy Fork is not here to host the images or whatever your script uses. Use a full URL and host them somewhere else.
Such requirements mean that to install a script from a local computer and to install it from the web you have to have different scripts. It's stupid. If you don't want to allow users storing resources on greasefork you should create redirects (Locatoon header) for userscripts stored as github repos.
No popular userscript hoster I know allows the feature you want here. And I also don't see the problem here:
- You can have second file containing only the resources part and change it easily by hand.
- You can create a small build script which inserts the requirements based on the script destination.
- You can have a git repository with two versions of the script in two branches and - as only the resources part differs let the changes auto merge in mostly all cases.
- You can link the GitHub resources in all scripts. This will only fail if you install the script on a computer with no internet connection. As the resources are downloaded with the script, you do not need an internet connection after download. The use case that you have no internet connection when you install a script from the computer is very rare and thus I don't see an reason why this should be supported as there are more important features which are not supported yet and affect a lot more developers.
A git repo shouldn't be tied to github. Git repos should be portable and work even if github fails without source code modifications. It's stupid to fetch files from github if you have them in local repo. Do you understand the mess created by adding github uris to every source every time you want to commit and removing them every time you want to test? Do you understand the mess created by having 2 branches only to have minor changes like gh uris in it? I don't think it should work this way.
No popular userscript hoster I know allows the feature you want here.
Userscripts.org allowed to provide a remote link to a script. I just inserted a link there and everything worked out of the box because the script was fetched directly from github.
Do you understand the mess created by adding github uris to every source every time you want to commit and removing them every time you want to test?
Depends on your development strategy. I do something like this. But with build scripts. So if I build a test script the test uris are added, If I build a release, the release uris are added. So I do not see a problem here as I do this myself (with some automation).
Do you understand the mess created by having 2 branches only to have minor changes like gh uris in it?
It's quite common to have a development branch and additionally a master / release branch. So in the develoment branch you use the local urls and in the master / release branch you use the github urls. I don't see a problem here as you then even can use the auto sync functionality from Greasyfork to only sync after a release commit / merge.
It's quite common to have a development branch and additionally a master / release branch.
Yes, it is. But the devolopment branch is used only to indicate that it is not stable and roots from a commit on master branch. There is no effort to make a dev branch master once it's ready other than style fixes and commit renaming/reordering.
And I don't understand why do you refuse to implement this, it doesn't look so hard to implement. All you have to do is to check if a script is hosted on github/other supported repo, create an url to the resource from the url to the script and relative url of the resource and give it to user using location header and 301. Otherwise return 404.
I am not saying that this should not be implemented at all. I will not complain if Jason has no objection and implements it (or if anyone makes a pull request which is accepted by Jason). I only don't see it as such a big problem as you and in my opinion there are more important things to do than implement a feature where you are the first after some years who requests it, as these other features help a bigger audience.