Add and use dependencies from another playground permalink

[infogulch]

I would like to reuse code saved in one playground in another, different playground without having to copy-paste the contents of the original, or having to publish it. This could be useful in several scenarios:

• 📚 Publishing some light library and reusing it in multiple pastes. If there are many copies of a paste with small differences (which I suspect is a common pattern), this could reduce total paste size and improve compile times for the playground runners by caching the dependencies' object files.
• 🐛 If someone is using a paste to demonstrate an issue with their code, reusing it as a dependency with some small tweak would naturally highlight the changes made and may aid their comprehension of the solution.
• 👨‍🏫 For education purposes, I could see a teacher create a paste that exposes public evaluation functions which must be called to clear some assignment. This would enable the student to focus on the assignment tasks and enables the teacher to know that the evaluation code was not tampered with.

👋 To use it, the playground could reserve a special module name pattern that would dynamically pull in other gists when referencing public items within it. 🚲 Bikeshedding notwithstanding, perhaps something like:

use gist_16aa5441c37dc67c7ce0c8b4b48c194b::{some_pub_fn, other_pub_fn};
// or under some namespace:
use playground::gist_16aa5441c37dc67c7ce0c8b4b48c194b::{some_pub_fn, other_pub_fn};

👩‍💻 I'm unsure exactly how this could be implemented. Maybe proc macros? A build.rs script that downloads the gist file before compilation? (this could even be reused outside of a playground environment [very carefully]). If using these features introduces undesirable attack surface, parsing the paste for use statements ahead of time could still be workable.

🔐 I don't think this would cause a material change to possible abuse cases. Obviously, gists saved by the playground are never changed so using another gist as a dependency could not cause pastes to break or cause some observable change in behavior. Total compilation+runtime would still be bounded by the playground runner. Dependencies would still have to be trees, and any code that uses this "paste splitting" feature could be automatically rewritten into a single file to review manually if needed.

Thoughts?

[shepmaster]

An interesting idea! Allow me to respond inline with a stream of consciousness...

---

Publishing some light library and reusing it in multiple pastes.

Believable, but it's hard to know how many people would use such a feature, and thus how much of a return-on-investment we might get.

If there are many copies of a paste with small differences (which I suspect is a common pattern), this could reduce total paste size

I don't exactly follow how — are you saying that someone would perform the work to extract the common code into this new library style and then just reference that?

improve compile times for the playground runners by caching the dependencies' object files.

I don't think this is a likely outcome. We really never want to share things between compilation sessions of different users.

If someone is using a paste to demonstrate an issue with their code, reusing it as a dependency with some small tweak would naturally highlight the changes made and may aid their comprehension of the solution.

Having a diff of sorts does seem useful, but I'm not following how it would work with this solution. If someone brings it in as a dependency, how would they then edit the dependency?

I could see a teacher create a paste that exposes public evaluation functions which must be called to clear some assignment. This would enable the student to focus on the assignment tasks

I agree (and I use the playground a lot for teaching purposes!).

and enables the teacher to know that the evaluation code was not tampered with.

How does this co-exist with the previous "with some small tweak"?

I don't think this would cause a material change to possible abuse cases.

I agree in general. The main problem I could see would be some form of DOS attack if we allowed recursive dependencies (especially if they were self-referential). That should be avoidable by only going one level deep.

---

Implementation wise, I can share some semi-planned future work that might make this more achievable. For a long time, people have been wanting to create multiple files, both for modules as well as multiple crates. I've been thinking about extending the playground's gist format to include a special TOML file (or something) that would allow us to store multiple files / a Cargo.toml / etc. If that happens, we could load that and rename the crate, leveraging normal Cargo packages.

That would make this feature mostly a front-end task focused on shuffling around the files appropriately.

[infogulch]

We really never want to share things between compilation sessions

Reasonable.

If someone brings it in as a dependency, how would they then edit the dependency?

Maybe this was a bit of a stretch, basically the 'library' code would have to be organized in a way to enable dependents to swap out parts. This should be possible to design intentionally, but I agree that it would not work for arbitrary code.

---

I've been thinking about extending the playground's gist format to .. store multiple files .. If that happens, we could load [a previous gist] and rename the crate, leveraging normal Cargo packages. That would make this feature mostly a front-end task focused on shuffling around the files appropriately.

This sounds like a great way to implement this feature.