Skip to content

Import sdist from distutils instead of setuptools #51

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

Merged
merged 1 commit into from
Oct 2, 2020

Conversation

jasongrout
Copy link
Member

@jasongrout jasongrout commented Oct 1, 2020

This fixes some issues we are seeing that stem from differences between distutils and setuptools.

See conda-forge/jupyterlab-feedstock#235 (comment)

This fixes some issues we are seeing that stem from differences between distutils and setuptools.
@jasongrout jasongrout merged commit dcbb6ba into jupyter:master Oct 2, 2020
jasongrout added a commit to jasongrout/jupyterlab that referenced this pull request Feb 12, 2021
In jupyter/jupyter-packaging#66, jupyter_packaging switched (back) to using setuptools rather than distutils for sdist. We had problems before with the staging directory not being included when using the setuptools sdist (see conda-forge/jupyterlab-feedstock#235 and jupyter/jupyter-packaging#51). It seems that the real problem we were experiencing was that when you have include_package_data=True, setuptools apparently does not include package_data files that are not given in MANIFEST.in (see pypa/setuptools#1461, for example).

This tries to get our packaging working with setuptools. We’ll be able to test this better when we actually do a release.

I tested with just running `python setup.py sdist` in a fresh checkout, and it ended up building the javascript in the staging directory, and then it included the build and node_modules directory. Thus I prune these out explicitly here. However, I think our normal build process does not build in that directory, but rather copies over files from the dev_mode directory, so the prune may not be needed in our normal build process. It doesn’t hurt to have it in, though.

It may be that we can consolidate these include statements, for example, perhaps we can just do “graft jupyterlab/staging”. However, I went for simplicity in closely mirroring what we have in package_data in setup.py.
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