Skip to content
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

ENH: add support for editable wheels #87

Merged
merged 20 commits into from
Dec 28, 2022
Merged

ENH: add support for editable wheels #87

merged 20 commits into from
Dec 28, 2022

Conversation

FFY00
Copy link
Member

@FFY00 FFY00 commented Jun 22, 2022

This is just an initial approach, that is known to not work on all
use-cases. It simply uses .pth files to inject search locations for the
default import finder, for this reason generated files that should be
installed inside modules will not be available.

Signed-off-by: Filipe Laíns [email protected]

@FFY00

This comment was marked as outdated.

@FFY00 FFY00 force-pushed the editable-wheels branch 2 times, most recently from 4a2b9df to 034d9d1 Compare November 25, 2022 08:03
@FFY00
Copy link
Member Author

FFY00 commented Nov 25, 2022

This new implementation uses import hooks, which is what I wanted to do initially. Since the complexity required to make the old approach work turned out to be a bit big, it makes more sense to do it like this from the start.

The idea is that we built on top of the Traversable protocol (EditablePath) and only trigger a rebuild when the data is accessed, this will delay rebuilds until the very last moment and prevent unnecessary rebuilds by just importing the module.

@dnicolodi
Copy link
Member

This is an interesting approach. Although I wonder how ergonomic it is. The main use of editable installations is during development. During development with compiled languages (which I think is the main target of meson-python) it is not unusual to do a recompilation just to check that the written code at least compiles. How would this work with approach? Also, does this still uses ephemeral build directories as the regular builds or does it default to a build directory inside the project folder? An example usage scenario would be great to have. Thank you!

@rgommers
Copy link
Contributor

During development with compiled languages (which I think is the main target of meson-python)

I'd say it is "Python projects containing compiled languages" - typically the majority of contributors (at least for large projects like NumPy, SciPy, Pandas) touch docs, tests, and pure Python code only, or at least way more often than native code.

I agree that when you're touching C/C++/Cython/Fortran, editable builds are less relevant. But I've had regular requests from collaborators for editable installs, in particular from those who work with IDEs.

@rgommers rgommers added the enhancement New feature or request label Nov 25, 2022
@rgommers
Copy link
Contributor

The way we've set it up for SciPy now to work with Meson is that running the test suite always first rebuilds (necessary to ensure the out-of-place install is not out of date). This takes a fraction of a second, so avoiding rebuilds on imports isn't essential I'd say. (not sure it matters regarding code complexity here).

@rgommers
Copy link
Contributor

The idea is that we built on top of the Traversable protocol (EditablePath) and only trigger a rebuild when the data is accessed, this will delay rebuilds until the very last moment and prevent unnecessary rebuilds by just importing the module.

The Python stdlib docs are extremely sparse as usual. I have to admit I don't immediately grasp how this all works, a sketch of what actually happens with this implementation when one runs pip install -e . and then import pkg would be useful.

@dnicolodi
Copy link
Member

I agree that when you're touching C/C++/Cython/Fortran, editable builds are less relevant.

I don't think that's the case. I do a lot of cross-project development where I need to test the changes in one project within another one. In this case editable installations are useful.

@lithomas1
Copy link
Member

Wow, this is pretty cool. Thanks for putting up the PR @FFY00.
I just have a couple quick clarifying questions.

For this to work, would every project would need to inject this hook(MesonpyFinder) into sys.meta_path in their init.py?


def install(path: str) -> None:
editable = Editable(os.path.abspath(path))
sys.meta_path.append(MesonpyFinder(editable))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would a prepend be more appropriate here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't matter much, but my reasoning for simply appending was to not slow down any of the other imports. But this is now outdated given our new approach.

@FFY00
Copy link
Member Author

FFY00 commented Nov 28, 2022

After discussing with @rgommers, we thought it would be better to simplify the initial approach. Instead of creating our own loader and reader, we will just intercept the import call with a custom finder, which won't change any of the import machinery and will simply trigger a rebuild + install to a dummy directory with we will make sure we add to sys.path. This means that the module would still be imported via the normal finder and loader. I think this will be easier to understand after you see the code.

@FFY00
Copy link
Member Author

FFY00 commented Nov 28, 2022

For this to work, would every project would need to inject this hook(MesonpyFinder) into sys.meta_path in their init.py?

Nop! Our editable wheel will install a .pth file that will do that. This code is still missing from the PR.

Also, the custom finder will need to be in sys.meta_path before the module is imported, as its goal is to hook into the import process, and the module __init__.py gets run on import, so that wouldn't work 😛

@@ -192,11 +188,15 @@ def _has_extension_modules(self) -> bool:
# Assume that all code installed in {platlib} is Python ABI dependent.
return bool(self._wheel_files['platlib'])

@property
def normalized_name(self) -> str:
return self._project.name.replace('-', '_')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related to editable installs: shouldn't this also map "." to "_"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! But not really here, though I should definitely be doing that in the module name.

@FFY00
Copy link
Member Author

FFY00 commented Nov 30, 2022

Alright, I haven't tested it yet, but it's getting pretty late, so I should go. The code should now be complete, but I expect stuff to be broken -- as I said, I didn't do any testing.

Copy link
Member

@dnicolodi dnicolodi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few superficial comments.

mesonpy/__init__.py Outdated Show resolved Hide resolved

project_path = self._source_dir / '.mesonpy-editable'
top_level_modules = self._project.top_level_modules
rebuild_commands = [list(cmd) for cmd in self._project.build_commands(project_path)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the list comprehension?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To convert to the correct type.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct type for what? This makes tuples into lists, but it does not seem like lists are required. Are they? If they are, can't we just return the correct type?

mesonpy/__init__.py Outdated Show resolved Hide resolved
Copy link
Member

@lithomas1 lithomas1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left some comments, addressing typos I saw when I pulled this. Hopefully, this helps you out a little.

Other then the suggestions, you'll need to add mesonpy/_editable to the meson.build file.

mesonpy/__init__.py Outdated Show resolved Hide resolved
mesonpy/__init__.py Outdated Show resolved Hide resolved
mesonpy/__init__.py Outdated Show resolved Hide resolved
mesonpy/__init__.py Outdated Show resolved Hide resolved
mesonpy/__init__.py Outdated Show resolved Hide resolved
@FFY00 FFY00 force-pushed the editable-wheels branch 2 times, most recently from 53512e0 to bd85f57 Compare November 30, 2022 19:09
@FFY00
Copy link
Member Author

FFY00 commented Nov 30, 2022

Alright, this should now be finally working 🎉

The only thing is that it currently does not detect top-level native modules.

@lithomas1 want to give it a try?

@lithomas1
Copy link
Member

lithomas1 commented Nov 30, 2022

Alright, this should now be finally working 🎉

The only thing is that currently does not detect top-level native modules.

@lithomas1 want to give it a try?

Nice this is pretty awesome 🚀 (It is especially cool that you can just edit .pyx files and have the changes sync up too).

The only issue I have is slow rebuilds.
I attached time.time() calls to measure the speed of rebuilds and currently its' taking ~3-4 seconds for a regular rebuild, and ~34 seconds(!!) when I modified a .pyx file.

It's not a deal-breaker for me, but its probably something to think about in the future.

@FFY00
Copy link
Member Author

FFY00 commented Nov 30, 2022

How does that compare to just running ninja directly? It shouldn't be taking much longer than that, and this is something we can't really do much about.
Using Traversables we should be able to avoid the extra install step, but that shouldn't take that long anyway. We could also try to optimize the import hook code, but I feel that will be insignificant compared to the build step.

Perhaps we should have a way to disable swallowing the Meson output, so that developers can see the log when Python starts up?

FFY00 added 15 commits December 23, 2022 13:16
This was leftover from when we ran auditwheel.

Signed-off-by: Filipe Laíns <[email protected]>
pytest has its own tmpdir management and cleanup, making is easier to
inspect the environments when the tests fail.

Signed-off-by: Filipe Laíns <[email protected]>
Dirty workaround for cases where Meson does not install to the expected
paths, like in macOS.

Signed-off-by: Filipe Laíns <[email protected]>
docs/index.rst Outdated

.. code-block::

python -m pip install -e . --config-settings editable-verbose=
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we error when this is passed but we are not doing an editable install?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep.

for key in config_settings:
known_keys = ('builddir', 'editable-verbose', *meson_args_cli_keys)
if key not in known_keys:
import difflib
matches = difflib.get_close_matches(key, known_keys, n=3)
if len(matches):
alternatives = ' or '.join(f'"{match}"' for match in matches)
raise ConfigError(f'Unknown configuration entry "{key}". Did you mean {alternatives}?')
else:
raise ConfigError(f'Unknown configuration entry "{key}"')

Copy link
Contributor

@rgommers rgommers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docs look quite good to me now, just a few minor suggestions to clarify things.

docs/index.rst Outdated Show resolved Hide resolved
docs/index.rst Outdated Show resolved Hide resolved
docs/index.rst Outdated Show resolved Hide resolved
docs/index.rst Outdated Show resolved Hide resolved
Copy link
Member

@lithomas1 lithomas1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@FFY00
Copy link
Member Author

FFY00 commented Dec 28, 2022

I somehow missed the notification for Ralf's review, so I only noticed yesterday 🤣

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants