-
-
Notifications
You must be signed in to change notification settings - Fork 252
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
Moves unnecessary deps out of critical build path #645
Moves unnecessary deps out of critical build path #645
Conversation
The only place they're seemingly used is in pgx-macros, so extracting them out of pgx-utils and putting them into macros might be ideal.
Also note that this branch is experimental for now, and the major reason for creating a pull request at this moment is to get CI to build it and see what results from the build. Depending on how that goes and the feedback given, this could very well end up in |
So I noticed you inlined single-consumer things into their consumers. |
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.
Thank you for taking a look at this!
I have some thoughts about a few more moves in this game of shufflepuck, but stripping pgx-utils down to almost the bare essentials is very nice to see.
* Removed pgx-paths (yes!) * Inlined versioned_so_name * Added "paths" methods into pgx-pg-config and exported appropriately
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 pgx-pg-sys-stub crate could probably still be moved in as a submodule in cargo-pgx.
@workingjubilee I added a couple new commits based on earlier discussions. Let me know what you think! |
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.
Excellent!
@workingjubilee One last closing thought before this gets merged in. We had talked about possibly renaming Do you feel that we should still do that? I bring it up since renaming it would (more than likely) break some things for any other project that relies on PGX, but since the next release is going to be breaking anyways it might be the best opportunity to do it. If it's something we should consider, then the best course of action might be to create a separate issue just for the rename, and maybe do it right before release so we're not stomping on all of the other incoming changes from the other contributors. The things I refactored out of |
Functionally, |
Ok, that's fair. I went ahead and made a new issue so that maybe we won't forget and perhaps visit in the future: #655 |
These are changes that coincide with #597
Mostly these changes are spent trying to pull out as much stuff out of
pgx-utils
where applicable, but there could be more to it as well.