-
-
Notifications
You must be signed in to change notification settings - Fork 0
Heavenly Hostas #18
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
base: main
Are you sure you want to change the base?
Heavenly Hostas #18
Conversation
Placeholder material taken from one of PyScript's official example projects (https://pyscript.com/@examples/webgl-icosahedron/latest)
…ler to resize canvas.
…rawing. Made script runnable from outside /editor
…ft on erase mode prior to the event
This reverts commit 4019d1f.
I think I messed something up so I redid the changes
… and type checking. Also with helper methods to organise functionality. minor ruff ignore rules added
Upload and download images feature
… and type checking. Also with helper methods to organise functionality. minor ruff ignore rules added
@PiLogic 's suggestions
…-README Update editor README.md
Add backend README
Add newline at end to fix linting issues
I fixed the wrong thing
Add ppt link
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.
The complete picture
Your project overall is a very ambitious one and executed fairly well. It's an interesting concept and all the different pieces of your project work quite well in concert. The code style is not quite cohesive, but we did only give you 10 days and a random team to code all this from the ground up. There are some areas of improvement, but nothing major or project-breaking. Well done!
README
The READMEs for all your project are fairly thorough. The backend one in particular is extremely detailed. Your primary project README does point to each project, but an explicit reference for which app to go to first would be appreciated.
Commits
From the sample of commits I reviewed and the commit messages together, they seem fairly good. Some of the commit messages could use improvement on what specifically the commit is doing. Otherwise the commits are incremental changes that are related and not large, monolithic updates which is good.
Code Quality
The code for the project as a whole is fairly solid. Within in each app there are improvements that could be made or minor errors. There is nothing critical or project-breaking though. Specific comments are left within this review, if you have any questions, answers, or clarifications feel free to comment! Broader project and file structure feedback is below.
The editor and gallery project may benefit from some restructuring. Particularly the editor application has a very large file that I think can be broken up into more logical pieces, such as splitting the file features and the shape features into their own files, and then importing them into the main file to be used. It'll let people get a better idea of the overall functionality available without needing to wade through the specific of how shapes are drawn or files dealt with.
The gallery project could also potentially benefit either from explicit editor #region declaration or splitting some of the room-centric features, mouse and movement controls, and other functionality into their respective files. This file is not as big, but I would take a look to see if it makes navigating the gallery project easier.
As a smaller note, I'm not certain the src/app and the __init__.py is necessary. Nothing jumped out at me immediately locking at the dockerfiles, but I could also have overlooked something.
| from gotrue import CodeExchangeParams, SignInWithOAuthCredentials, SignInWithOAuthCredentialsOptions | ||
| from pydantic import BaseModel | ||
|
|
||
| from . import env, gh, pg, sb |
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.
Commenting here, but the filenames should be more descriptive and spelled out. Two letter shorthands are a bit hard to parse when it's half of the files for the backend. Especially for sb for Supabase which is not as commonly known as gh for GitHub.
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.
I think it may have started out with sb for Supabase, because the Python module itself is called supabase, so obviously that was not an option for my utility file, I suppose I could have gone with supabase_utils.py or something, but evidently I decided for sb, may have been influenced by my shortened usage of env for the environment module and then gh and pg just followed the same pattern essentially and I knew that those two were relatively more well known abbreviations.
I guess it would have been better to name them all github_utils.py, postgres_utils.py, supabase_utils.py, but at that point you wonder if they should go into a utils package where you'd call them github.py, postgres.py, and then what? supabase.py is off the table as previously established, so what are your suggestions in that case? Perhaps, despite being moved to a utils directory, they should still maintain their _utils.py suffixes, that kinda makes sense to me at least.
| allow_methods=["*"], | ||
| allow_headers=["*"], |
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.
This is fine for development, but typically for proudction you want to restrict this to specific headers and specific methods.
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.
That does make sense in terms of being more specific regarding security, but what real threats could it actually pose? I can imagine that say if I didn't want to receive some Authorization header from this other site for some reason, I'd disallow it, but I don't see a particular danger with allowing it, especially so as the origin in this case is trusted anyway.
Also I'm not sure we even need CORS support anyway. It was originally intended so that we could host the editor in an iframe (because it still needed a back end server since it uses NiceGUI), so that both the gallery and the editor could be under the same domain, but the editor needs to use session cookies for handling, well, user sessions. So, for certain requests, like publishing, we'd need to include those cookies in the request headers, however, the request would be coming from a different origin than where the cookies are set. I thought it could be solved with CORS, but apparently browsers just won't include cookies tied to another domain from a different domain regardless of CORS settings, so that failed spectacularly and the editor was just kept on the same domain the cookies would be set. (Obviously, we couldn't do anything that would involve interacting with the back end of GH pages)
(wait, is CORS what allows the client to send direct requests (from the browser) to a different origin? maybe we do need the CORS configuration after all, in which case I suppose a potential attack vector would be if the trusted origin got compromised and somebody could send any request on the behalf of a user without them even knowing to this other service and impersonate them, but I mean, if the trusted (in this case anyway) origin were to be compromised, we'd have some bigger issues, lol)
| def assure_get_env(var: str) -> str: | ||
| """Get an environment variable or raise an error if it is not set.""" | ||
| value = os.getenv(var) | ||
| if value is None: | ||
| msg = f"Environment variable '{var}' is not set." | ||
| raise OSError(msg) | ||
| return value |
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.
This function is only used in env.py from what I can tell. I would probably just move it into that file itself, especially since the env.py is not intended to be a file the person setting it up edits.
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.
This seems to be a relic from before the envs.py file existed and the environment variables were loaded in __init__.py and then potentially this function was also called in sb.py too? Either way, it's a bit of a legacy in that sense, it's a good refactoring point. Though I suppose it's possible that in the future the envs.py file might become a bit too small for all the environment variables and you'd want to read them in their own respective files? Not sure.
|
|
||
| CLIENT_ID = utils.assure_get_env("CLIENT_ID") | ||
| CLIENT_SECRET = utils.assure_get_env("CLIENT_SECRET") | ||
| PRIVATE_KEY = Path("pydis-cj12-heavenly-hostas-app.private-key.pem").read_text().strip() |
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.
All other env vars throw an error if it's not present. Should this be the case for the PRIVATE_KEY as well?
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.
Well, it will throw a FileNotFoundError if that key file does not exist
| # Get SHA of the data branch to create a new branch off of in the fork | ||
| # r = await client.get( | ||
| # f"https://api.github.com/repos/{env.GIT_UPSTREAM_OWNER}/{env.GIT_UPSTREAM_REPO}/git/refs/heads/{env.GIT_UPSTREAM_DATA_BRANCH}", | ||
| # headers=headers, | ||
| # ) | ||
| # r.raise_for_status() | ||
| # base_sha = r.json()["object"]["sha"] |
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.
This can probably just be removed if it's not necessary.
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.
Yep, seems like it (I sometimes like to keep commented out code in case I want to go back to it (I suppose there's version control which should be handling this, but it's not always an option, because in this case what I think happened, was, I wrote this code, it didn't work, I commented this bit out, tried hardcoding that SHA, that worked, so I committed it (and if I had deleted this commented out bit, it would've been effectively lost))
At this stage though, sure, removing it is probably fine.
|
|
||
|
|
||
| def tp_to_slot(slot: int) -> None: | ||
| print(f"Going to image on index {slot}...") |
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.
A good avenue for future improvement is to convert these print statements into proper logging statements.
| async def main(): | ||
| await load_images_from_listing() | ||
|
|
||
| while not SCENE.getObjectByName("room_0_0"): |
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.
Is there something special about this particular room? Could help to be explicit about it in a comment.
| CAMERA.position.set(chunk_x * apothem * 2, CAMERA.position.y, chunk_z * apothem * 2) | ||
|
|
||
|
|
||
| def url_process() -> None: |
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.
A docstring for this function would be immensely helpful since it is a function that's called relatively early and seems to do something important.
| return ROOM_TYPES._4, 0 | ||
| # no exit | ||
| case z if not any(z): | ||
| assert False |
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.
I would rather raise an exception here instead of an assert. You can provide more information and in general I don't love assert usage in non-testing code since it can be disabled by running the interpreter with different settings.
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.
Didn't know that last thing, you're totally right on that then!! 😅
| description = "An online Image Gallery rendered through Three.js and WebGL and programmed in PyScript." | ||
| readme = "README.md" | ||
| requires-python = ">=3.12" | ||
| dependencies = [] |
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.
I think you may have a few dependencies such as pyscript and pyodide.
That was motivated by a potentially outdated (or even false altogether) belief regarding the That said, the commit that adds this change has a very suspicious message, maybe |
No description provided.