External data directory #510
Conversation
| Flit will package these with no special configuration. | ||
|
|
||
| However, sometimes it's useful to package external files for system integration, | ||
| such as man pages or files defining a Jupyter extension. To do this, arrange |
There was a problem hiding this comment.
perhaps
which rely on well-known paths such as ``man`` pages or defining a Jupyter `extension <https://jupyter-server.readthedocs.io/en/latest/developers/extensions.html>`_ or `kernel <https://jupyter-client.readthedocs.io/en/stable/kernels.html#kernel-specs>`_. To do this, arrange😊 sorry, I'm sure there's a better way to do this in
.rst...
There was a problem hiding this comment.
I'm torn on this, but for now I think I'll leave the links out. Jupyter has quite a few different extension points, and I don't want this to grow into a list of ways to extend Jupyter (not that such a list shouldn't exist, but it should be in Jupyter's own docs ;-).
|
|
||
| For users coming from setuptools: external data corresponds to setuptools' | ||
| ``data_files`` parameter, although setuptools offers more flexibility. | ||
|
|
There was a problem hiding this comment.
Perhaps a note/warning on how/if-at-all this works with editable installs, and how one might go about handling developing these?
There was a problem hiding this comment.
Thanks, I'm adding a note. They'll get installed, but with a pip install -e development install, they're just copied, so you have to reinstall if anything changes (I don't think PEP 660 really lets us do anything else). If you use flit install --symlink, individual files are symlinked, so you only have to reinstall when adding/removing them.
|
I'll leave this another day or two for any other maintainers (or anyone else!) to look at, otherwise I think it's ready. |
| if data_dir is not None: | ||
| toml_key = "tool.flit.external-data.directory" | ||
| if not isinstance(data_dir, str): | ||
| raise ConfigError(f"{toml_key} must be a string") |
There was a problem hiding this comment.
Do you want to add tests for these error branches, that codecov is complaining aren't covered?
There was a problem hiding this comment.
It feels too much like testing that the code I've written is the code that's there, which always feels a bit pointless. If someone wants to add some test cases and push coverage up a bit, I'm happy enough to merge it, but I don't feel like it's worth spending time on.
If someone finds a case where it's currently doing the wrong thing, I'm happier to add a test for that as we fix it.
|
Just want to say, perfect. Simple solution that does exactly what I want, no complicated mapping/rename etc, just plain and simple 👍 |
Corresponding to setuptools'
data_files, but less flexible: you just get one directory, which will be mapped to wherever the installer decides to put the 'data' component of the wheel (typically the prefix path).Closes #358.