Add back setup.py for editable installations #1224
Conversation
|
I was pretty happy to finally be able to remove |
Honestly, I have no idea. All this |
|
I'd say you best add your |
|
Here's the corresponding setuptools documentation. pypa/setuptools#2816 |
|
You can have an editable install with: I'd prefer using |
This commit adds a 2-line (3-line, if you count the blank line) `setup.py` script that provides the bare minimum needed to support packaging with `setuptools`, e.g.: ```shell python3 setup.py sdist bdist_wheel ``` This basic `setup.py` should also support editable installations, as requested in nschloe#1223. The basic rationale for `setuptools` packaging is for high-performance computing sites that lag behind in software tooling. While projects like Spack help update this tooling to permit updating sometimes ancient toolchains, HPC site policies -- including the HPC site I work at -- sometimes require repackaging Python packages from source for internal approval and security auditing, as well as for portable installation to air-gapped machines. While I completely agree that `setup.py` is a relic -- and to that effect, just spent a few hours adding source code and binary wheel installations of `flit_core`, `flit`, `pep517`, and `build` to my HPC site for approval -- it's much, much easier to point to upstream code than it is to have to figure out that these lines must be added for bespoke packaging, add them, look through project documentation like `CONTRIBUTING.md`, discover through looking at pull requests and issues on GitHub that such a pull request may not be accepted, and then figure out how to pass that information on to security auditors and colleagues. If this solution is unacceptable, I welcome other suggestions, including writing a statement to the effect of "Pull requests adding a `setup.py` file will not be accepted to this repository" somewhere in documentation, along with the suggested solution of adding ```python from setuptools import setup setup() ``` or similar to a local copy of the repository so as to avoid the sorts of discussions seen in nschloe#1224.
|
I realise this is an older PR, but it's probably unnecessary now. Pip has had support for
|
|
Thanks for the follow up @GenevieveBuckley! Indeed this is unnecessary as of now. I finally bit the bullet and familiarized with pyproject.toml since this was opened |
Resolve #1223