search

UpliftGames / wally

Wally is a modern package manager for Roblox projects inspired by Cargo
https://wally.run
Mozilla Public License 2.0
317 stars 102 forks source link

RFC: Should wally assume the use of rojo? #142

Open magnalite opened 1 year ago

magnalite commented 1 year ago

Should wally assume the use of rojo?

Update: https://github.com/UpliftGames/wally/issues/142#issuecomment-1591259112

I am now considering this our current plan for how we will be moving forward unless anyone has any further concerns.

We can refine these ideas as we go and I am open to all changes and suggestions. I will give this RFC at least another 2 weeks for people to add their ideas, feelings and concerns. After 2 weeks I will consider it safe to start working on any changes which require this assumption of rojo however I will leave it open up until we reach that point, however long that takes. Once we do reach that stage I will close this issue and consider it our new philosophy moving forward.

Up until now wally has been intentionally agnostic to how users are building their projects. Its only role is to get them their packages. I consider this to be a generally healthy attitude for wally to have due to these reasons:

  1. Users may want to use another tool than rojo
  2. We should focus on getting users their packages, not how they use them
  3. Fewer hard requirements for the build process can lead to a higher adoption rate (wally should work with everything)

While wally is used by "power users" this is fine however I see this attitude becoming increasingly problematic as wally becomes more user friendly. We are already in a weird situation where wally is intentionally blind to you using rojo but you are unable to use wally in any reasonable capacity if you are not using rojo. Every package currently on wally assumes you are using rojo. If you tried to use some other method then every package on wally would be painful to use.

The situation outlined above means you are required to use rojo if you wish to use wally. However with wallys blindness to rojo it can make creating packages a real pain. There is currently no guidance or convenient default behaviour to assist users getting started with making a rojo compatible package. Knowing how to structure your default.project.json file is not trivial. Knowing how to sync your package into a test place as a sibling among other packages is not trivial. If we want to widen the adoption of wally we need to make creating and testing packages as easy as possible and right now it is not easy!

There is also the question of what happens if users start using something other than rojo? Let's take the example of Roblox releasing a native studio filesystem sync effectively making rojo obsolete. While unlikely, I see this as the most likely situation for a mass migration away from rojo. What would we even do in this situation? Do we mass migrate every package to a new compatible form on behalf of package owners? Do we add an abstraction interface to translate between rojo and native studio formats? Do we just let the community sort it out on their own but maybe add rojo/native tags to make discoverability easier? In every scenario we would need to be acutely aware of rojo to make the registry remotely friendly to use. Maybe a solution could be to make an entirely new registry; label the old one rojo-only and the new one native-only. This entire scenario is something we should prepare for at some point.

Proposal for the reasonable assumption of rojo

I would like to propose a formal assumption that wally users will be using rojo. There is an important caveat to this which is we may have to support other build methods, such as native studio sync mentioned above, and so we should make efforts to ensure such a transition is as easy as possible. We should also never prevent people from just getting packages or publishing packages which do not require rojo.

In a practical sense this assumption would mean:

I now believe formally assuming the use of rojo to use wally, until external circumstances change, is healthier for the overall development of wally. Awareness of rojo will likely lead to a far better user experience both for users of rojo and users who choose another method (due additions like to metadata tagging). What do you all think?

Kampfkarren commented 1 year ago

+1 in favor of assuming Rojo, though we should make sure we're not totally locked into it in the off chance Roblox makes their own thing, for instance.

ccuser44 commented 1 year ago

I would be a bit hesitant to lock users of wally to a single build system

autonordev commented 1 year ago

Imo it's important that users are not locked into particular workflows by their tools unless absolutely necessary. I think that metadata indicating on a package level whether Rojo or another build system (e.g. custom/bespoke, FileSyncService, etc) is used would be wise to add and - even if no features come from knowing if Rojo is used - provides useful information and may be critical in the future if additional build systems become popular.

It's also worth noting that it's not impossible for (consumed) packages to support multiple or even several different build systems. With regards to the specific opportunities assumption presents, features like auto generating files should be opt-in (or at least opt-out) nevertheless.

I can't see a reason against recommending the use of Rojo and documentation reflecting that. In fact, I view this as a good thing which could help to increase Wally's adoption and make life easier for less-experienced users.

magnalite commented 1 year ago

To clarify I am 100% agreeing that users should never be locked into a particular workflow. This is simply a change in philosophy to make wally "rojo aware" and heavily encourage the use of rojo through quality of life additions. These additions will never block you from using another method but for the time being those other methods will see minimum level support until they reach significant adoption.

The first concrete concept I'd like to start with introducing is the idea of a package being "rojo-compatible". That is declaring the package will work with a rojo workflow. Note however that does not mean it is locked to rojo. For example if roblox ever released a native sync method a package could conceivably be "rojo-compatible" and "roblox-native-compatible". There may be better terminology we could use here but this gets the idea across for now. Maybe supported-workflows = [ "rojo", "roblox-native" ] as the user facing terminology but I believe rojo-compatible best semantically defines what we are trying to do here.

For existing packages we don't know if they are rojo-compatible however we could inspect them to check. I see this inspection as a necessary addition to ensure a project is safe to be labeled rojo-compatible as above. If we cannot determine if a package is rojo-compatible then the list of compatible workflows is just empty. I think it is important that whatever we do here it can support all existing packages on the registry in some convenient way.

Once we know what workflows a package is compatible with, in this case rojo, we can add an enrichment step to actions we do. For example suggesting rojo defaults. Enforcing the package will work correctly with rojo. Analysing what is used by rojo and only publishing that to the registry by default (but can be overridden). There are lots of wins here - but they all work in addition to the existing workflow to improve it in an after-the-fact way. Ie wally does what it needs to and only then enriches the experience with QoL additions.

And as part of this "reasonable assumption of rojo" we assume that rojo will be the workflow a user chooses and focus on making these QoL additions for it. We can always add enrichment steps to other workflows in the future but only if they pick up significant traction. For now we don't need to concern ourselves with them beyond ensuring we can support them in the future.

I am now considering this our current plan for how we will be moving forward unless anyone has any further concerns.

We can refine these ideas as we go and I am open to all changes and suggestions. I will give this RFC at least another 2 weeks for people to add their ideas, feelings and concerns. After 2 weeks I will consider it safe to start working on any changes which require this assumption of rojo however I will leave it open up until we reach that point, however long that takes. Once we do reach that stage I will close this issue and consider it our new philosophy moving forward.

ffrostfall commented 1 year ago

I'm a bit late to the party but I definitely support the move to Wally assuming Rojo usage.

filiptibell commented 1 year ago

I like the idea of wally being aware of different tooling and runtimes, and would like to propose an alternative name / syntax instead of supported-workflows:

target = "rojo"
target = "roblox-native"
target = "lune" # Supports a different runtime
target = ["rojo", "roblox-native", "lune"] # Supports roblox tooling *and* a completely different runtime

This draws inspiration from the compiled programming languages world where compilation "targets" are common, as well as web tooling where a "target" could be where the application will run once it has been bundled up using a bundler, such as native / browser, ... I am also personally a fan of the style of supporting either a straight up string or a list of strings for options like these, it tends to simplify configuration for the 99% of users that will only ever use one runtime/toolchain

LastTalon commented 1 year ago

I'm in favor of this move. It can be all too easy to worry about what happens in the future and remain agnostic while hurting real usability. The fact is that right now people use this with rojo and that should be easy to do. That has to come with the caution that we don't make assumptions that force the use of a particular tool or category of tools, but it shouldn't stop us from making it work nicely for the tools we have.