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

introduce an entry points interface for loading modules #140

Merged
merged 11 commits into from
Dec 4, 2022
Merged

Conversation

tonyfast
Copy link
Member

@tonyfast tonyfast commented Nov 29, 2022

to me, this is a significant change to importnb because it feels like the new api surface for importing alternative documents. the new interface looks like:

with imports("ipynb", "json", "yaml", "toml"):
     import Untitled, package, mkdocs, pyproject

the context manager resolves the [project.entry-points.importnb] definitions and appends the loader associated with them to the sys.path_hooks. within the context, any of the aliased loaders are free game for python to import.

this approach allows other packages to make their loaders available to a single API. midgy, a package for using markdown files as python scripts, defines the md entry point. so with midgy installed:

with imports("md"):
     import README
  • new entry_points source
  • docstrings and tests
  • command line support - import a file and get a pretty repr
  • pass arguments to imports
  • documentation

code is not special

we're in the midst of adopting computational literacy as mass literacy. code is everywhere and people are eager to learn it. they are finding coding embedded in common file formats like markdown, docx, pptx, pdf, zip, ... it is in every nook and cranny of daily life. being restrictive about what is code will exhaust the enforcer.

importnb started as a way to avoid copy/pasting code from jupyter notebooks to python to test it efficacy;
the redundancy in work seemed counterintuitive. as a tool, importnb allow us to hide a lot of complex logic that might hinder the literary quality of a notebook. it allowed us to use notebooks to talk about notebooks, and, as always, we had fun doing it.

ultimately, importnb became a powerful tool for tuning the literary qualities of notebooks for docs, demos, and blogs.
it allowed us to tell more complex stories by encapsulating logic in different notebook documents.
ultimately, importnb and these inclusive importing features exist for the sake of the story; they exist as literary devices.

the concept of importing non-python documents seems consistent with the message in computer programming for everybody. i feel like part of that mission requires a more inclusive perspective on what is code. one way to express this belief is to permit imports of othered code.

problems

  • disambiguation - what happens when there are two md or csv or parquet loaders
  • you have environment problems when you need an extension

@tonyfast
Copy link
Member Author

well fuck a 🦆! in order to have entry points, we need an optional dependency for importlib.metadata for python 3.7 only. i think it still counts as no deps, at least in a few months it will be true.

@tonyfast tonyfast merged commit 2c692ee into main Dec 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant