Question: Target editable install

[blink1073]

Hi @ofek, thanks for this library!

Based on your comment in setuptools about External Data, I am exploring using hatch as a wholesale replacement for jupyter_packaging.

One thing I am stuck on is how to run a specific build script during the editable wheel build phase.

I am happy to provide an example for the documentation if you give me the right spelling. 😄

[blink1073]

My naive guess would be something like tool.hatch.build.hooks.wheel:editable

[ofek]

Hey thank you, I'd be happy to help with that!

Relevant docs for a quick custom hook: https://hatch.pypa.io/latest/plugins/build-hook/#custom

hatch_build.py:

from hatchling.builders.hooks.plugin.interface import BuildHookInterface

class CustomHook(BuildHookInterface):
    def initialize(self, version, build_data):
        if self.target_name != 'wheel' or version != 'editable':
            return

        ...

[ofek]

If you do:

[tool.hatch.build.targets.wheel.hooks.custom]

rather than

[tool.hatch.build.hooks.custom]

then you don't need the self.target_name != 'wheel' check

[blink1073]

Ideally we wouldn't have to write a BuildHookInterface at all, so that our extension cookiecutter could simply have a script that was called before building an editable wheel/standard wheel/sdist. Otherwise I think we might as well use an in-tree build backend as we recently did with ipyparallel, or else have to write another library similar to jupyter_packaging on top of hatch.

What I'm hoping for is something similar to cibuildwheel's before build. We currently have used the following interface in jupyter-packaging:

[tool.jupyter-packaging.builder]
factory = "jupyter_packaging.npm_builder"

[tool.jupyter-packaging.build-args]
build_cmd = "build:src"

[ofek]

Could you maintain something like ipython/ipyparallel/buildapi.py as a build hook plugin like hatch-mypyc? Then it could be versioned and updated for everyone!

For example, if you implement the PLUGIN_NAME as jupyter then the user config would look like:

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[project]
name = "new-jupyter-pkg"

[tool.hatch.build.targets.wheel.hooks.jupyter]
dependencies = ["hatch-jupyter-pkg-name"]
some-custom-option1 = "..."
some-custom-option2 = "..."

[blink1073]

I like that idea! We can have a jupyter one for general use across our projects, and a jupyterlab one that specifically handles jupyterlab extensions, which have a more complicated behavior and set of dependencies.

[blink1073]

I'll propose the solution this week to the relevant teams.

[ofek]

How did it go?

[blink1073]

I didn't make the meetings this week, but I talked to a fellow maintainer and I'm going to take a spike with a hatch plugin and see if I can get something that works for ipykernel. That one is a good target because there is both an ipykernel package and an ipykernel_launcher.py module, AND it has different build steps for sdist/wheel vs editable wheel.

[blink1073]

(flit doesn't support multiple top level packages/modules)

[blink1073]

So far so good! ipython/ipykernel#931

[blink1073]

WIP plugin: https://github.com/blink1073/hatch_jupyter_builder

[ofek]

Wow awesome! One critique: I think for consistency the TOML config options should be hyphenated e.g. build_function -> build-function. PEP 621 chose this and Hatch followed suit.

[blink1073]

Sounds good, thanks!