Thanks for making it clear the intended workflow is to fork a gist. I might recommend making that actually part of the application suite, even. I guess I need

Thanks for making it clear the intended workflow is to fork a gist. I might recommend making that actually part of the application suite, even. I guess I need to look deeper into how SharpScript does things to get the proper terminology going, but, by way of explanation, I use Python in my day job. As such, I was thinking along the lines of "how do I deploy a SharpScript Gist App with several Gist dependencies?". In Python-land this would minimally be a Python script in a file and a requirements.txt file. The requirements.txt file typically is a line-delimited file that has package names (or URLs, importantly) with optional version specifiers. Since the Python Package Index is immutable, if I specify package "foo==1.2.3", I can be relatively certain that I will retrieve that package and that version, even if there are newer versions or the author deletes their upstream source control repository. Anyway, I'm basically wondering what the SharpScript Gist Application approach will be to say "This script depends upon these gists with these versions". I'm advocating for the default method to always specify a particular immutable version of a gist, otherwise, you will run the risk of these "always updated" gists changing in unexpected ways including malicious ones that perhaps check to see if they are on a CI server and steal credentials, etc. Circling back to the top, I think if the only route to be sure that you have a permanent and immutable copy of a Gist Application is to fork it, then I further advocate that the SharpScript tooling should make this as easy as `sharp fork url-to-gist`.