Closed Technici4n closed 1 year ago
Other reasons to use Yarn include parameters and javadocs :)
It's worth noting that both myself and apple are avid yarn contributors while also being Fabric discord moderators, and to properly maintain the cleanroom would have to avoid this channel, potentially leading to a lack of moderation in it compared to other channels... could this be an issue?
Other reasons to use Yarn include parameters and javadocs :)
There is parchment for that, so that's not an advantage in favor of either. ;) However, unpick is only available for yarn at the moment. I'll edit the post.
It's worth noting that both myself and apple are avid yarn contributors while also being Fabric discord moderators, and to properly maintain the cleanroom would have to avoid this channel, potentially leading to a lack of moderation in it compared to other channels... could this be an issue?
This is possible in theory. However the development channels usually require less moderation, and I think we also can't really know whether this is an issue in practice without trying it.
If you make the decision to move away from Yarn, then it may be worth pulling out the constant unpicking system into some other tools - we could make use of that system also.
Food for thought, perhaps.
The goal is not to move away from yarn for the time being, rather reflect that a lot of modders using Fabric are using mojmap. But we have/want to maintain the cleanroom, so yarn should remain the default choice, and mojmap should remain separate.
However I think that the constant unpicking system could be used by Forge/Parchment too, possibly with a separate unpick database. Here is an example from Fabric's database: https://github.com/FabricMC/yarn/blob/23w17a/unpick-definitions/set_block_state_flags.unpick. The system is already quite detached: https://github.com/FabricMC/unpick, but I am not sure how much glue is required to add it to a gradle plugin.
(By "database" I mean the data used to perform the unpicking).
Ah, I didn't mean to imply that you'd be removing Yarn entirely - allowing a different mappings set in the toolchain would mean that certain workspaces would have this unpicking and others wouldn't, determined entirely by the mappings set used. This may be confusing to people in support channels when referring to sections of code that now refer to integer constants.
Unpicking, at its most basic level, isn't a function of the mappings set, but rather a system used in the creation of such.
Pulling that out to be generic and available to every mappings provider, is what I was talking about.
Perhaps it would be easier to discuss this more in-depth on the Discord.
allowing a different mappings set in the toolchain would mean that certain workspaces would have this unpicking and others wouldn't, determined entirely by the mappings set used
This is already true since all tooling allows for different mapping sets. Mojang mappings don't have Unpick definitions when used by modders.
I'm glad you all are finally joining the world of the sensible :) I do agree though, it would be nice to work on getting a set of unpick definitions into ideally Parchment or perhaps an associated project for us to all use
Yeah, it'd be nice to have unpicking available for everyone. Also note that Yarn's unpick definitions can't be reused fully even if they're modified to use Mojang names – some of them reference Yarn's compile-only constant holder classes.
If it makes sense, couldn't some of those constant holder classes also be added to Parchment with different naming?
They're free to use under CC0 and are just lists of fields, so that would be both allowed and very simple. See for example LlamaVariants
. (The other classes are similar)
Perhaps it would be worthwhile to have a separate issue or discussion for the matter of unpicking. This isn't quite relevant to the topic of the issue at hand, and I don't wish to clog up relevant discussion too much.
Personally I am less concerned about keeping yarn a pure "cleanroom". Yarn was originally developed as a clean room to protect against MCP's strict ARR license at the time. However I think its impossible to be a cleanroom from mojang's own names, and not worth the effort (If mojang wanted to stop us, they could have done years ago in 100 other ways).
We already use mojang's own names that are also plastered all over the codebase in strings, records and what not. (Technically not under the license of the mappings, but close enough)
Im not suggesting we start accepting PRs that are 1-1 copy pastes of mojmap, nor accept PRs that are only possible with mojmap (unmapable constants). I do think we can be less strict about it, and not worry if names are inspired or accidentally copied from Mojmap.
Thus I propose we allow the talk of Mojmap in the discord/github (expect yarn github). Yarn contributors wont need to be fearful of reading conversations (It's highly likely yarn will already have a name for it anyway).
Unpick is something we can easily solve 👍
Allowing Mojmap names on Fabricord but requiring them to be put behind a spoiler would also be an acceptable solution IMO
My opinion on the matter is that like how the fabric discord communicates in english as a common language, we have to have only one mapping in nornal discussions.
The only exception I could see this working in is if we had a mod-dev-other-mappings channel where people would have to state their mapping before seeking assistance.
This would keep the other channels in yarn as well as allow for users of different mappings(not just mojmaps) to ask for help on the discord.
It should also be considered that the main advantage(at least in my opinion) of yarn is that it is spoken by the people who provide help in most dev channels on the discord and for that reason it should be encouraged.
From what I see in #mod-devX, the people that use mojmaps in their questions don't even know that they are doing it most of the time or they don't know that rule 8 exists (and let's skip the ones that don't even look at the channel list to begin with). The majority of them will still ask in #mod-devX and be told to move to the new channel, so a major waste of time.
There is no enforced yarn cleanroom, and rule 8 don't stop a contributor to come up with a mojmap name on its own, it actually make the situation worse because if the goal of rule 8 was to protect yarn, then discovering that "ABC" is a mojmap name would let the contributor do a better job at NOT using mojmaps names in yarn. And an automated tool that rejects mojmaps names from contributions will solve the problem once and for all.
So, just drop rule 8
Note: this is my own opinion and not moderator's opinion.
Dropping rule 8 is a good suggestion. Here's why:
Copy-pasting Player's message:
The rules were updated to allow using proprietary mappings outside influencing yarn development (don't use them to argue around yarn naming)
Proposal
Given the current popularity of mojmap (Mojang Mappings) for Fabric modding, I don't think it's fair to exclude it entirely from the server. I suggest that we introduce one new channel:
mod-dev-mojmap
. Thanks to discord's onboarding feature, we can make it hidden by default, and users will have to opt-in. It's hard to estimate how much traffic it would get, so I suggest that we start with one channel for now, and possibly extend it in the future. Would like to hear everyone's thoughts.Background
My goal is to give developers who are using mojmap a channel where they can get help, I am not suggesting that Fabric API switch from yarn to mojmap or yarn be abandoned in any way.
I will also stress that we cannot allow mentions of mojmap in all channels as it would threaten the yarn cleanroom.
And now, a few reasons to use either set of mappings, for background - there are valid arguments for both:
Reasons to use mojmap
Reasons to use yarn
Note: While mojmap doesn't include method and parameter names, parchment exists to provide that on top of mojmap. Hence I have not included this as an advantage for yarn.