Add developer install instructions #1223
Comments
|
I just use tox for testing and install it with from pypi or |
|
But then you cannot edit the source and it be reflected in the environment. For example check this out: I updated the init of diff --git a/src/meshio/__init__.py b/src/meshio/__init__.py
index 035ae53..36c81ae 100644
--- a/src/meshio/__init__.py
+++ b/src/meshio/__init__.py
@@ -80,3 +80,5 @@ __all__ = [
"topological_dimension",
"__version__",
]
+
+print('this has been editted')But then if I import meshio into Python, I cannot see that change: $ meshio git:(main) ✗ python
Python 3.8.8 | packaged by conda-forge | (default, Feb 20 2021, 16:12:38)
[Clang 11.0.1 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import meshio
>>>In order to see the change I have to install it again: $ meshio git:(main) ✗ pip install .
...
$ meshio git:(main) ✗ python
Python 3.8.8 | packaged by conda-forge | (default, Feb 20 2021, 16:12:38)
[Clang 11.0.1 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import meshio
this has been editted
>>>Without a |
|
How about tox? |
|
Well the point is that I want to use |
This is also what I found. |
|
For the time being, you could simply add a |
|
Yep, that's what I did 👍 |
|
A bit embarrassingly, this took me about an hour to figure out. IMO, meshio should keep a setup.py until the new package config can support editable installations |
|
Or at least dev install instructions outlining the need for this file |
Fair enough, fair enough. I'll add one. |
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.
does not work on Python 3.8 after cloning
It appears the setup.py was removed (without warning?) in #795
Since the typical way of installing isn't working, there should be an explanation of the usage of
setup.cfgin the README and how to install this locallyThe text was updated successfully, but these errors were encountered: