-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: replaced all whitelist and blacklist occurences by allowlis… #5277
base: develop
Are you sure you want to change the base?
Conversation
…t and blocklist We want to demonstrate our openness and inclusiveness in our code Resolves MovingBlocks#5275
This is eerily reminding me of #5276 - my apologies @byhlel for thinking you may also be a bot or some sort of AI-assisted PR generator, but I'd like to ask for some sort of sign of humanity before considering this PR. Like just saying hello and what brought you here, and confirming that you've actually been able to run the game from source with the updates in place? |
Hey, Also checking my profile would have reassured you on the latter. |
Oh phiew then - thanks for the quick reply, just a weird timing issue with the other PR and the barebones PR description. Maybe a tool that partially auto-created the PR out of a commit message or something? I'd also be curious how you ran it on a VM, when trying in the past here that has gone ... poorly :-) Any VM-induced performance issues aside so long as it builds and runs that's probably enough to call it validated 👍 Although, considering that a rename of config files is included for a headless server run, that might be worth a quick check as well. And I wonder if we had any part of that automated for the test server setup / stored game server images we use 🤔 This shouldn't be too bad to try out though, so maybe myself or another maintainer can check that soon. I'm on parental leave and have pretty minimal time, just spotted this by chance. I'll try to keep this in a tab near the top of my browser and see if I can get to it :-) Much appreciated! |
No I just like to keep my commits as concise as possible and respecting the repo's guideline. Seems fine to me but further review to make sure nothing was accidently broken might be relevant here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this. We have sadly had pull requests that were very suspect in the recent past but they were clearly so (like #5264) and nothing like this. We are quite happy to accept quality contributions from anyone.
Ordinarily though, renaming APIs would be a breaking change that would need a strong justification to warrant large-scale changes to our module ecosystem.
The changes here, however, appear minimal and only affect internal APIs, so I see no harm in accepting it, so long as backwards compatiblity is maintained. Currently with these changes whitelist.json
and blacklist.json
will no longer be read. If you could change this to accept both old and file names still then it should work well.
.gitignore
Outdated
# Ignore Whitelist and Blacklist files | ||
whitelist.json | ||
blacklist.json | ||
# Ignore Allowlist and Denylist files | ||
allowlist.json | ||
denylist.json |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we please retain the old flle names in the gitignore so that they are not accidentally committed from older workspaces in future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
applied
docs/Modding-API.md
Outdated
@@ -1,13 +1,13 @@ | |||
Modding API | |||
================= | |||
|
|||
Terasology's engine uses a whitelisting approach to expose an API for modules using two primary methods and a rarely needed third one: | |||
Terasology's engine uses allowlisting approach to expose an API for modules using two primary methods and a rarely needed third one: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Terasology's engine uses allowlisting approach to expose an API for modules using two primary methods and a rarely needed third one: | |
Terasology's engine uses an allowlisting approach to expose an API for modules using two primary methods and a rarely needed third one: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or alternatively:
Terasology's engine uses allowlisting approach to expose an API for modules using two primary methods and a rarely needed third one: | |
Terasology's engine uses allowlisting to expose an API for modules using two primary methods and a rarely needed third one: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
applied
blacklistPath = PathManager.getInstance().getHomePath().resolve("blacklist.json"); | ||
whitelistPath = PathManager.getInstance().getHomePath().resolve("whitelist.json"); | ||
denylistPath = PathManager.getInstance().getHomePath().resolve("denylist.json"); | ||
allowlistPath = PathManager.getInstance().getHomePath().resolve("allowlist.json"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is likely to a breaking change otherwise, can we continue to check for the old file names if the newer ones do not exist?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
applied
engine/src/main/java/org/terasology/engine/rendering/nui/layers/mainMenu/SelectGameScreen.java
Show resolved
Hide resolved
…bility Code strucutre is different in SelectGameScreen and ServerConnectListManager due to compiling error otherwise. We check if path exist then we set the value if it does, otherwise it applies "previous" behaviour (meaning in case if even blacklist or whitelist) do not exist it sets the file to null. So no different behaviour is to be expected.
Yes thank you for pointing this out, hadn't thought much of backwards compatibility! |
Path blacklistPath = PathManager.getInstance().getHomePath().resolve("blacklist.json"); | ||
Path whitelistPath = PathManager.getInstance().getHomePath().resolve("whitelist.json"); | ||
if (!Files.exists(blacklistPath)) { | ||
Path denylistPath = PathManager.getInstance().getHomePath().resolve("denylist.json"); | ||
Path allowlistPath = PathManager.getInstance().getHomePath().resolve("allowlist.json"); | ||
if (!Files.exists(denylistPath)) { | ||
denylistPath = PathManager.getInstance().getHomePath().resolve("blacklist.json"); | ||
} | ||
|
||
if (!Files.exists(allowlistPath)) { | ||
allowlistPath = PathManager.getInstance().getHomePath().resolve("whitelist.json"); | ||
} | ||
if (!Files.exists(denylistPath)) { | ||
try { | ||
Files.createFile(blacklistPath); | ||
Files.createFile(denylistPath); | ||
} catch (IOException e) { | ||
logger.error("IO Exception on blacklist generation", e); | ||
logger.error("IO Exception on denylist generation", e); | ||
} | ||
} | ||
if (!Files.exists(whitelistPath)) { | ||
if (!Files.exists(allowlistPath)) { | ||
try { | ||
Files.createFile(whitelistPath); | ||
Files.createFile(allowlistPath); | ||
} catch (IOException e) { | ||
logger.error("IO Exception on whitelist generation", e); | ||
logger.error("IO Exception on allowlist generation", e); | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand this logic, it is not quite correct. I was not paying full attention last time to this area. Now it creates blacklist.json
and whitelist.json
files if no files are present, I think. It should never create new blacklist.json
and whitelist.json
files, so if those are present then the check for the corresponding new names can just be skipped.
All that this code should be doing is creating empty files if they do not exist, rather than trying to load them in. As such, it should not be creating files with the old names and should skip creating files with the new names if those old-named files are already present.
// although this seems redundant, compiler wouldn't accept assigning then checking | ||
if (Files.exists(PathManager.getInstance().getHomePath().resolve("denylist.json"))) { | ||
denylistPath = PathManager.getInstance().getHomePath().resolve("denylist.json"); | ||
} else { | ||
denylistPath = PathManager.getInstance().getHomePath().resolve("blacklist.json"); | ||
} | ||
// although this seems redundant, compiler wouldn't accept assigning then checking | ||
if (Files.exists(PathManager.getInstance().getHomePath().resolve("allowlist.json"))) { | ||
allowlistPath = PathManager.getInstance().getHomePath().resolve("allowlist.json"); | ||
} else { | ||
allowlistPath = PathManager.getInstance().getHomePath().resolve("whitelist.json"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// although this seems redundant, compiler wouldn't accept assigning then checking | |
if (Files.exists(PathManager.getInstance().getHomePath().resolve("denylist.json"))) { | |
denylistPath = PathManager.getInstance().getHomePath().resolve("denylist.json"); | |
} else { | |
denylistPath = PathManager.getInstance().getHomePath().resolve("blacklist.json"); | |
} | |
// although this seems redundant, compiler wouldn't accept assigning then checking | |
if (Files.exists(PathManager.getInstance().getHomePath().resolve("allowlist.json"))) { | |
allowlistPath = PathManager.getInstance().getHomePath().resolve("allowlist.json"); | |
} else { | |
allowlistPath = PathManager.getInstance().getHomePath().resolve("whitelist.json"); | |
} | |
// Check for old naming first to retain compatiblity, otherwise use new naming by default. | |
Path potentialDenylistPath = PathManager.getInstance().getHomePath().resolve("blacklist.json"); | |
Path potentialAllowlistPath = PathManager.getInstance().getHomePath().resolve("whitelist.json"); | |
if (!Files.exists(potentialDenylistPath)) { | |
potentialDenylistPath = PathManager.getInstance().getHomePath().resolve("denylist.json"); | |
} | |
if (!Files.exists(potentialAllowlistPath)) { | |
potentialAllowlistPath = PathManager.getInstance().getHomePath().resolve("allowlist.json"); | |
} | |
denylistPath = potentialDenylistPath; | |
allowlistPath = potentialAllowlistPath; |
denylistPath
and allowlistPath
are final variables, so they can only be assigned once in the constructor. Using a temporary variable here should work (but I wrote this quickly so please test that it compiles and works).
…t and blocklist
We want to demonstrate our openness and inclusiveness in our code
Resolves #5275
Contains
Resolves #5275
How to test
Everything works as before
Outstanding before merging