Improve docs and behavior of editable installs #3414
Conversation
Improve chances that symlinks are tested directly on the relevant file system (some machines might have multiple disks with different link support).
docs/userguide/development_mode.rst
Outdated
| Editable installs are **not a perfect replacement for regular installs** | ||
| in a test environment. When in doubt, please test your projects as | ||
| installed via a regular wheel. There are tools in the Python ecosystem, | ||
| like :pypi:`tox` or :pypi:`nox`, that can help you with that. |
There was a problem hiding this comment.
Just a minor point, but doesn't tox use sdist by default and rely on a plugin for wheel?
There was a problem hiding this comment.
I think you don't exactly need a plugin to achieve that with tox...
It seems that the default behaviour is to build an sdist file and then use pip install... If that is the case, pip install will internally build a wheel in the final step before installing anyway. (The sdist creation can be forced to follow PEP 517 with the isolated_build config).
Additionally, a developer could use:
-
install_command config.
-
--installpkgCLI flag, pointing to a wheel.
Maybe it would be good to confirm this behaviour with the tox developers.
Do you have any suggestions?
There was a problem hiding this comment.
Just complementing some words like tox (with appropriate configuration) and nox would fine for me.
BTW, what is an effective way to understand the difference between editable/wheel install, after I tried pip install . in my testing virtualenv?
There was a problem hiding this comment.
Thank you very much for the suggestions @kngwyu! I will add those in a follow up review.
BTW, what is an effective way to understand the difference between editable/wheel install, after I tried pip install . in my testing virtualenv?
Let's say your are creating a mypkg with a __main__.py module like the following:
# mypkg/__main__.py
print("hello world")When you do pip install ., pip will create a wheel that will correspond to a "snapshot in time" of your package. So if later you change the print statement to print("hello universe") in your project folder, your package will still display the old message:
$ cd /tmp # let's change the directory to avoid messing with PYTHONPATH
$ python -m mypkg
hello worldIf you did an editable install instead pip install -e ., then it would display the updated message:
$ cd /tmp
$ python -m mypkg
hello universeIf you feel like the docs could improve, please feel free to add suggestions, they are always welcome!
Thank you very much for the kind words @kngwyu. Please feel free to add any suggestions. (Also note that this PR is valid for the |
|
@kngwyu (and other members of the community), please feel free to add more suggestions. I am more then happy to address them in follow-up PRs. |
PR pypa#3414 added support for disabling the new PEP660 editable install hooks. However the documentation and changelog mentions didn't match the implementation. Before: - The implementation used: `SETUPTOOLS_ENABLE_FEATURES` - The changelog said to use: `SETUPTOOLS_ENABLE_FEATURE` (notice the missing "S") - The docs said to use: `SETUPTOOLS_USE_FEATURE` This caused confusion in pypa#3535, since the testcase there used the form mentioned in the changelog, which doesn't do anything. Now, the changelog and docs both say to use `SETUPTOOLS_ENABLE_FEATURES`.
2 participants
(Another PR of the PEP 660 series)
Summary of changes
SETUPTOOLS_ENABLE_FEATURE=legacy-editableCloses
Pull Request Checklist
changelog.d/.(See documentation for details)