-
Notifications
You must be signed in to change notification settings - Fork 77
ENH: remove the need for a working directory & other cleanups #364
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
Conversation
6083699
to
c2ee830
Compare
The macOS test failure are the same found in #348 and will have the same solution. |
8e71ace
to
8b496b6
Compare
Thanks @dnicolodi. Trying to think of a merge strategy here - I think the status is:
|
I see this more like preparation work for landing #348 with the resulting code being in better shape (if we agree that the resulting code after merging this PR is "better"). From a "build things from the ground up" point of view, I would merge this and rebase the fixes in #348 on top. Or we can do the other way around and have this merged after #348 to cleanup the implementation. I think merging this first results in less (or easier to resolve) rebase conflicts and will make looking the commit history easier, but we can go either way. This PR being ready to be merged, while the proper solution for the rpath issues in #348 are still being discussed, is one reason to have this merged first. If you want to merge with all green tests, I can mark the rpath test as I can take care of rebasing #348 on top of this. The tests for |
32b372a
to
a580617
Compare
@rgommers I added the |
I think you have a branch for this already, right? If so, would you mind sharing for some testing? If not, please don't worry about it now. |
No, I don't. If that is the desired way forward, it should not take more than few minutes to prepare it. |
PR #348 rebased on top of this is here https://github.com/dnicolodi/meson-python/tree/pr348 |
I removed the v0.13.0 milestone, as this getting in is not critical for it, and we should release 0.13.0 as soon as we are able to. If this is in shape to get in by the time we sort the release blockers, great, otherwise we can just merge it afterwards and have it in 0.14.0. |
This is ready to be merged since a long time. It just needs a review. I don't understand why you think otherwise. |
It conflicts with #348, which needs to get in for the new release. |
I already posted the conflict resolution. |
But the PR may get more changes before merging. If you have an updated PR by then, great, we can merge it, otherwise we just do it for the next release. |
What's the problem with merging this now, rebase #348 on top, and take it from there? |
It can unnecessarily delay the release. Like I said, this is not critical, unlike the other PR, so I am not merging this now. |
This PR hasn't even been reviewed btw, so it might still require changes, etc. I am prioritizing the release blockers. |
d93c2f6
to
f64f914
Compare
abaeb0c
to
b79c87b
Compare
Looking up keys in a default dict adds these keys to the dictionary with their default value when they are not present. This is an issue if the lookup happens while the dictionary is being iterated. Avoid it.
This will matter later when intall_path() will get an absolute path into the installation directory rather than a path into the source or build directory.
f97ff4d
to
ee3cf79
Compare
Currently a Project has an associated a temporary working directory containing the build directory (unless the user specifies another one via configuration options) and the install directory for the meson project. The code can be simplified assigning to the project a build directory and always using a temporary install directory. Note that currently all files are copied into the Python wheel from the source or build directory, thus running meson install into a destination directory is not that useful. This will be addressed in later commits.
ee3cf79
to
cd2894c
Compare
@rgommers I left out the commits with behavior changes from this PR. This is now just refactoring and a change in the structure of temporary directories. It would be nice to have this merged as a first step toward fixing the linked issues. |
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 @dnicolodi. Restructuring this to have no behavior changes was helpful. Sorry it took so long to review. I verified this as well as I could, and tested with SciPy - it all looks good. The code is easier to understand after this - and the simplifications in the tests are a good sign too. So in it goes.
@dnicolodi WDYT about tagging a 0.14.0 release? The PR queue is pretty much empty, so now would be a good time. We can quickly do a 0.15.0 too in case the subsequent PR to this one arrives quickly. |
Thanks for the review @rgommers. I'll prepare a PR with the actual fixes |
I don't know how critical it is to push a release with the fixes that already landed in |
It's not critical to do it right this minute, so let's wait for at least the fixes for the bugs that don't depend on a new Meson release? I'm also going through the backlog now and see what can be closed or easily addressed. Some of the documentation issues are straightforward, I'll try to fix a couple after dinner. |
This brings back the simplifications I proposed in #340 in a way compatible with having the wheel generated from files installed by
meson install
in a temporary destination directory. This covers a very minimal part of the work done in #348 too. It should be trivial to rebase #348 on top of this.Fixes #355 and #330 as there are no arguments the user can supply that would interfere with meson-python internals. It also fixes #317 in the same way as #348 does.