-
Notifications
You must be signed in to change notification settings - Fork 12
Remove python folder #449
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?
Remove python folder #449
Conversation
|
/help |
GiGL Automation@ 20:53:17UTC : 🤖 Available PR CommandsYou can trigger the following workflows by commenting on this PR:
💡 Usage: Simply comment on this PR with any of the commands above (e.g., ⏱️ Note: Commands may take some time to complete. Progress updates will be posted as comments. |
|
/unit_test_py |
|
/integration_test |
GiGL Automation@ 21:01:02UTC : 🔄 @ 21:14:56UTC : ❌ Workflow failed. |
GiGL Automation@ 21:01:06UTC : 🔄 @ 21:18:15UTC : ❌ Workflow failed. |
GiGL Automation@ 21:01:29UTC : Starting to build base images for CUDA and CPU. |
GiGL Automation@ 21:11:56UTC : Built and pushed new images:
Updated |
|
/unit_test_py |
GiGL Automation@ 03:27:43UTC : 🔄 @ 04:22:11UTC : ✅ Workflow completed successfully. |
|
/integration_test |
GiGL Automation@ 03:27:57UTC : 🔄 @ 04:20:45UTC : ❌ Workflow failed. |
|
/integration_test |
GiGL Automation@ 06:16:28UTC : 🔄 @ 07:23:00UTC : ✅ Workflow completed successfully. |
GiGL Automation@ 06:17:56UTC : Starting to build base images for CUDA and CPU. |
GiGL Automation@ 06:26:49UTC : Built and pushed new images:
Updated |
|
/e2e_test |
GiGL Automation@ 16:39:32UTC : 🔄 @ 18:01:50UTC : ❌ Workflow failed. |
|
/unit_test |
GiGL Automation@ 17:04:36UTC : 🔄 @ 17:13:14UTC : ✅ Workflow completed successfully. |
GiGL Automation@ 17:04:41UTC : 🔄 @ 18:18:19UTC : ✅ Workflow completed successfully. |
kmontemayor2-sc
left a comment
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 verify this works internally too?
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.
Do we need to update the compile_protos rule too?
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.
We do, let me look into it.
Thanks for the good eye.
| .lib/ | ||
| python/gigl/env/customer.yaml | ||
| python/gigl/deps/ | ||
| gigl/env/customer.yaml |
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.
lol what even is this file?
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.
not blocking just curious :)
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.
some legacy artifact that we moved away from years ago yet is still 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.
Hmmm - in the end, what do we want the docker file structure to look like? Is this it?
There's still this /gigl_deps this we use.
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.
GiGL deps will probably stick around as its more a directory that hosts the gigl python virtual env and deps for docker base images.
The GiGL source images are rebuilt every code change but deps remain static unless there is a new dep
|
|
||
| COPY gigl gigl | ||
| COPY snapchat snapchat | ||
| COPY tests tests |
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.
why do we need tests 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.
ditto generally.
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.
Unsure what the consequences of removing it are, and tbh I did not block myself on testing this as my goal was to keep existing logic and just delete the folder.
I was going to add a follow up task to see if we can remove this. Let me do this now: #456
| """Returns the parent directory of GiGL""" | ||
| file_path = Path(__file__) | ||
| path = LocalUri(file_path.parents[5]) | ||
| path = LocalUri(file_path.parents[4]) |
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.
unrelated but can we explain this magic number? Something like
| ) # gigl/experimental/knowledge_graph_embedding/ |
| @@ -4067,7 +4067,7 @@ object GbmlConfig extends scalapb.GeneratedMessageCompanion[snapchat.research.gb | |||
| * Path to modeling task spec class path to construct model for inference. Used for the subgraph-sampling-based inference process. | |||
| * @param inferenceBatchSize | |||
| * Optional. If set, will be used to batch inference samples to a specific size before call for inference is made | |||
| * Defaults to setting in python/gigl/src/inference/gnn_inferencer.py | |||
| * Defaults to setting in igl/src/inference/gnn_inferencer.py | |||
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.
| * Defaults to setting in igl/src/inference/gnn_inferencer.py | |
| * Defaults to setting in gigl/src/inference/gnn_inferencer.py |
nit.
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.
Do we need to update this too?
https://github.com/Snapchat/GiGL/blob/main/pyproject.toml#L253-L263
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.
good call
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.
Hmmm, I think it's a bit odd we have both tests/ and testing/ now. I remember there was a reason I named it testing. #185 (comment)
But it seems like that should no longer be an issue if we move testing to tests (or vise-versa).
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.
Probably fine to do as a follow up fwiw.
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.
👍 #457
|
@kmontemayor2-sc addressed ur comments. Re:
See: go/gigl-issue/1465 |
kmontemayor2-sc
left a comment
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.
Have we verified that we can still release/etc with these changes?
We should probably have a version bump with this (and update CHANGELOG)
Otherwise, LGTM but I'd prefer we can verify everything works internally first :)
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.
QQ why do we need this now?
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.
/shrug.
I didn't touch this file.
Merging artifacts?
Nonetheless, this is already a common practive to have __init__.py file in every module/submodules.
No, mostly because release (the wheel) is broken right now and this PR is a prerequisite to me fixing the release process.
I am planning to have a version bump and subsequent release when the release wheel is fixed - which I am working on right now. |
As more PRs go into GiGL the burden of work here to constantly update and test this scales tremendously as this will conflict with every* PR. You can track the progress here go/gigl-issue/1465; which should be resolved soon |
mkolodner-sc
left a comment
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.
GiGL Automation@ 20:47:13UTC : 🔄 @ 22:04:38UTC : ✅ Workflow completed successfully. |
mkolodner-sc
left a comment
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 Shubham! Generally LGTM conditioned on all testing passing
Scope of work done
Our source code has lived in
GiGL/pythonfor a while.Although this was fine when the repo was first created, it has since became a headache as we need to make special considerations when handling it in code, when reading bundled yamls, resolution for IDEs, building docker images, et al.
This is also making it harder to bundle static files (non source code) in wheels; thus I am opting to remove it.
Where is the documentation for this feature?: N/A
Did you add automated tests or write a test plan?
Ran testing suite in comments below; addressed fixes as needed.
Updated Changelog.md? NO
Ready for code review?: YES