aboutsummaryrefslogtreecommitdiff
path: root/python/setup.cfg
AgeCommit message (Collapse)AuthorFilesLines
2021-09-27python: add optional pygments dependencyG S Niteesh Babu1-0/+5
Added pygments as optional dependency for AQMP TUI. This is required for the upcoming syntax highlighting feature in AQMP TUI. The dependency has also been added in the devel optional group. Added mypy 'ignore_missing_imports' for pygments since it does not have any type stubs. Signed-off-by: G S Niteesh Babu <niteesh.gs@gmail.com> Message-Id: <20210823220746.28295-5-niteesh.gs@gmail.com> Signed-off-by: John Snow <jsnow@redhat.com>
2021-09-27python: Add entry point for aqmp-tuiG S Niteesh Babu1-0/+1
Add an entry point for aqmp-tui. This will allow it to be run from the command line using "aqmp-tui localhost:1234" More options available in the TUI can be found using "aqmp-tui -h" Signed-off-by: G S Niteesh Babu <niteesh.gs@gmail.com> Message-Id: <20210823220746.28295-4-niteesh.gs@gmail.com> Signed-off-by: John Snow <jsnow@redhat.com>
2021-09-27python/aqmp-tui: Add AQMP TUIG S Niteesh Babu1-1/+12
Added AQMP TUI. Implements the follwing basic features: 1) Command transmission/reception. 2) Shows events asynchronously. 3) Shows server status in the bottom status bar. 4) Automatic retries on disconnects and error conditions. Also added type annotations and necessary pylint/mypy configurations. Signed-off-by: G S Niteesh Babu <niteesh.gs@gmail.com> Message-Id: <20210823220746.28295-3-niteesh.gs@gmail.com> Signed-off-by: John Snow <jsnow@redhat.com>
2021-09-27python: Add dependencies for AQMP TUIG S Niteesh Babu1-0/+8
Added dependencies for the upcoming AQMP TUI under the optional 'tui' group. The same dependencies have also been added under the devel group since no work around has been found for optional groups to imply other optional groups. Signed-off-by: G S Niteesh Babu <niteesh.gs@gmail.com> Message-Id: <20210823220746.28295-2-niteesh.gs@gmail.com> Signed-off-by: John Snow <jsnow@redhat.com>
2021-09-27python/aqmp: Add Coverage.py supportJohn Snow1-0/+10
I'm not exposing this via the Makefile help, it's not likely to be useful to passersby. Switch the avocado runner to the 'legacy' runner for now, as the new runner seems to obscure coverage reports, again. Usage is to enter your venv of choice and then: `make check-coverage && xdg-open htmlcov/index.html`. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-28-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-09-27python: bump avocado to v90.0John Snow1-1/+1
Avocado v90 includes improved support for running async unit tests. The workaround that existed prior to v90 causes the unit tests to fail afterwards, however, so upgrade our minimum version pin to the very latest and greatest. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-25-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-09-27python/pylint: disable no-member checkJohn Snow1-0/+1
mypy handles this better -- but we only need the workaround because pylint under Python 3.6 does not understand that a MutableMapping really does have a .get() method attached. We could remove this again once 3.7 is our minimum. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-19-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-09-27python/pylint: disable too-many-function-argsJohn Snow1-0/+1
too-many-function-args seems prone to failure when considering things like Method Resolution Order, which mypy gets correct. When dealing with multiple inheritance, pylint doesn't seem to understand which method will actually get called, while mypy does. Remove the less powerful, redundant check. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210915162955.333025-17-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-09-27python/pylint: Add exception for TypeVar names ('T')John Snow1-0/+1
'T' is a common TypeVar name, allow its use. See also https://github.com/PyCQA/pylint/issues/3401 -- In the future, we might be able to have a separate list of acceptable names for TypeVars exclusively. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20210915162955.333025-4-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-09-27python/aqmp: add asynchronous QMP (AQMP) subpackageJohn Snow1-0/+1
For now, it's empty! Soon, it won't be. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20210915162955.333025-2-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-09-16python: pylint 2.11 supportJohn Snow1-1/+1
We're not ready to enforce f-strings everywhere, so just silence this new warning. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Message-id: 20210916182248.721529-3-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-09-16python: Update for pylint 2.10John Snow1-0/+1
A few new annoyances. Of note is the new warning for an unspecified encoding when opening a text file, which actually does indicate a potentially real problem; see https://www.python.org/dev/peps/pep-0597/#motivation Use LC_CTYPE to determine an encoding to use for interpreting QEMU's terminal output. Note that Python states: "language code and encoding may be None if their values cannot be determined" -- use a platform default as a backup. Notes: Passing encoding=None will generate a suppressed warning on Python 3.10+ that 'None' should not be passed as the encoding argument. This behavior may be deprecated in the future and the default switched to be a ubiquitous UTF-8. Opting in to the locale default will be done by passing the encoding 'locale', but that isn't available in 3.6 through 3.9. Presumably this warning will be unsuppressed some time prior to the actual switch and we can re-investigate these issues at that time if necessary. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Message-id: 20210916182248.721529-2-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-09-01python: Reduce strictness of pylint's duplicate-code checkJohn Snow1-0/+5
Pylint prior to 2.8.3 (We pin at >= 2.8.0) includes function and method signatures as part of its duplicate checking algorithm. This check does not listen to pragmas, so the only way to disable it is to turn it off completely or increase the minimum duplicate lines so that it doesn't trigger for functions with long, multi-line signatures. When we decide to upgrade to pylint 2.8.3 or greater, we will be able to use 'ignore-signatures = true' to the config instead. I'd prefer not to keep us on the very bleeding edge of pylint if I can help it -- 2.8.3 came out only three days ago at time of writing. See: https://github.com/PyCQA/pylint/pull/4474 Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Acked-by: John Snow <jsnow@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20210809090114.64834-3-eesposit@redhat.com> Signed-off-by: Hanna Reitz <hreitz@redhat.com>
2021-07-13python: Configure tox to skip missing interpretersWainer dos Santos Moschetta1-0/+1
Currently tox tests against the installed interpreters, however if any supported interpreter is absent then it will return fail. It seems not reasonable to expect developers to have all supported interpreters installed on their systems. Luckily tox can be configured to skip missing interpreters. This changed the tox setup so that missing interpreters are skipped by default. On the CI, however, we still want to enforce it tests against all supported. This way on CI the --skip-missing-interpreters=false option is passed to tox. Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Message-Id: <20210630184546.456582-1-wainersm@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Cleber Rosa <crosa@redhat.com>
2021-06-30python: only check qemu/ subdir with flake8John Snow1-2/+0
flake8 is a little eager to check everything it can. Limit it to checking inside the qemu namespace directory only. Update setup.cfg now that the exclude patterns are no longer necessary. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Tested-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Message-id: 20210629214323.1329806-11-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-30python: Re-lock pipenv at *oldest* supported versionsJohn Snow1-1/+3
tox is already testing the most recent versions. Let's use pipenv to test the oldest versions we claim to support. This matches the stylistic choice to have pipenv always test our oldest supported Python version, 3.6. The effect of this is that the python-check-pipenv CI job on gitlab will now test against much older versions of these linters, which will help highlight incompatible changes that might otherwise go unnoticed. Update instructions for adding and bumping versions in setup.cfg. The reason for deleting the line that gets added to Pipfile is largely just to avoid having the version minimums specified in multiple places in config checked into the tree. (This patch was written by deleting Pipfile and Pipfile.lock, then explicitly installing each dependency manually at a specific version. Then, I restored the prior Pipfile and re-ran `pipenv lock --dev --keep-outdated` to re-add the qemu dependency back to the pipenv environment while keeping the "old" packages. It's annoying, yes, but I think the improvement to test coverage is worthwhile.) Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Message-id: 20210629214323.1329806-5-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-30python: Remove global pylint suppressionsJohn Snow1-3/+1
These suppressions only apply to a small handful of places. Instead of disabling them globally, disable them just in the cases where we need. The design of the machine class grew quite organically with tons of constructor and class instance variables -- there's little chance of meaningfully refactoring it in the near term, so just suppress the warnings for that class. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Message-id: 20210629214323.1329806-4-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-30python: expose typing information via PEP 561John Snow1-0/+4
https://www.python.org/dev/peps/pep-0561/#specification Create 'py.typed' files in each subpackage that indicate to mypy that this is a typed module, so that users of any of these packages can use mypy to check their code as well. Note: Theoretically it's possible to ditch MANIFEST.in in favor of using package_data in setup.cfg, but I genuinely could not figure out how to get it to include things from the *source root* into the *package root*; only how to include things from each subpackage. I tried! Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Message-id: 20210629214323.1329806-3-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-18python: add qmp-shell entry pointJohn Snow1-0/+1
now 'qmp-shell' should be available from the command line when installing the python package. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210607200649.1840382-42-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-18python/qemu-ga-client: add entry pointJohn Snow1-0/+1
Remove the shebang, and add a package-defined entry point instead. Now, it can be accessed using 'qemu-ga-client' from the command line after installing the package. The next commit adds a forwarder shim that allows the running of this script without needing to install the package again. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210604155532.1499282-11-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-18python/qmp: add fuse command to 'qom' toolsJohn Snow1-0/+1
The 'fuse' command will be unavailable if 'fusepy' is not installed. It will simply not load and subsequently be unavailable as a subcommand. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210603003719.1321369-20-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-18python: add optional FUSE dependenciesJohn Snow1-1/+8
In preparation for moving qom-fuse over to the python package, we need some new dependencies to support it. Add an optional 'fusepy' dependency that users of the package can opt into with e.g. "pip install qemu[fuse]" which installs the requirements necessary to obtain the additional functionality. Add the same fusepy dependency to the 'devel' extras group -- unfortunately I do not see a way for optional groups to imply other optional groups at present, so the dependency is repeated. The development group needs to include the full set of dependencies for the purpose of static analysis of all features offered by this library. Lastly, add the [fuse] extras group to tox's configuration as a workaround so that if a stale tox environment is found when running `make check-tox`, tox will know to rebuild its environments. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210603003719.1321369-17-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-18scripts/qom-fuse: add static type hintsJohn Snow1-0/+8
Because fusepy does not have type hints, add some targeted warning suppressions. Namely, we need to allow subclassing something of an unknown type (in qom_fuse.py), and we need to allow missing imports (recorded against fuse itself) because mypy will be unable to import fusepy (even when installed) as it has no types nor type stubs available. Note: Until now, it was possible to run invocations like 'mypy qemu/' from ./python and have that work. However, these targeted suppressions require that you run 'mypy -p qemu/' instead. The correct, canonical invocation is recorded in ./python/tests/mypy.sh and all of the various CI invocations always use this correct form. Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210603003719.1321369-16-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-18python: Add 'fh' to known-good variable namesJohn Snow1-3/+4
fd and fh are fine: we often use these for "file descriptor" or "file handle" accordingly. It is rarely the case that you need to enforce a more semantically meaningful name beyond "This is the file we are using right now." While we're here: add comments for all of the non-standard pylint names. (And the underscore.) Signed-off-by: John Snow <jsnow@redhat.com> Message-id: 20210603003719.1321369-10-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-18python/qmp: add qom script entry pointsJohn Snow1-0/+8
Add the 'qom', 'qom-set', 'qom-get', 'qom-list', and 'qom-tree' scripts to the qemu.qmp package. When you install this package, these scripts will become available on your command line. (e.g. when inside of a venv, `cd python && pip install .` will add 'qom', 'qom-set', etc to your $PATH.) Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20210603003719.1321369-6-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add tox supportJohn Snow1-1/+22
This is intended to be a manually run, non-CI script. Use tox to test the linters against all python versions from 3.6 to 3.10. This will only work if you actually have those versions installed locally, but Fedora makes this easy: > sudo dnf install python3.6 python3.7 python3.8 python3.9 python3.10 Unlike the pipenv tests (make venv-check), this pulls "whichever" versions of the python packages, so they are unpinned and may break as time goes on. In the case that breakages are found, setup.cfg should be amended accordingly to avoid the bad dependant versions, or the code should be amended to work around the issue. With confidence that the tests pass on 3.6 through 3.10 inclusive, add the appropriate classifiers to setup.cfg to indicate which versions we claim to support. Tox 3.18.0 or above is required to use the 'allowlist_externals' option. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Tested-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-31-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add avocado-framework and testsJohn Snow1-0/+1
Try using avocado to manage our various tests; even though right now they're only invoking shell scripts and not really running any python-native code. Create tests/, and add shell scripts which call out to mypy, flake8, pylint and isort to enforce the standards in this directory. Add avocado-framework to the setup.cfg development dependencies, and add avocado.cfg to store some preferences for how we'd like the test output to look. Finally, add avocado-framework to the Pipfile environment and lock the new dependencies. We are using avocado >= 87.0 here to take advantage of some features that Cleber has helpfully added to make the test output here *very* friendly and easy to read for developers that might chance upon the output in Gitlab CI. [Note: ALL of the dependencies get updated to the most modern versions that exist at the time of this writing. No way around it that I have seen. Not ideal, but so it goes.] Provided you have the right development dependencies (mypy, flake8, isort, pylint, and now avocado-framework) You should be able to run "avocado --config avocado.cfg run tests/" from the python folder to run all of these linters with the correct arguments. (A forthcoming commit adds the much easier 'make check'.) Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Tested-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-28-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add devel package requirements to setuptoolsJohn Snow1-0/+9
setuptools doesn't have a formal understanding of development requires, but it has an optional feataures section. Fine; add a "devel" feature and add the requirements to it. To avoid duplication, we can modify pipenv to install qemu[devel] instead. This enables us to run invocations like "pip install -e .[devel]" and test the package on bleeding-edge packages beyond those specified in Pipfile.lock. Importantly, this also allows us to install the qemu development packages in a non-networked mode: `pip3 install --no-index -e .[devel]` will now fail if the proper development dependencies are not already met. This can be useful for automated build scripts where fetching network packages may be undesirable. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-27-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: move .isort.cfg into setup.cfgJohn Snow1-0/+8
Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-24-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add mypy to pipenvJohn Snow1-0/+1
0.730 appears to be about the oldest version that works with the features we want, including nice human readable output (to make sure iotest 297 passes), and type-parameterized Popen generics. 0.770, however, supports adding 'strict' to the config file, so require at least 0.770. Now that we are checking a namespace package, we need to tell mypy to allow PEP420 namespaces, so modify the mypy config as part of the move. mypy can now be run from the python root by typing 'mypy -p qemu'. A note on mypy invocation: Running it as "mypy qemu/" changes the import path detection mechanisms in mypy slightly, and it will fail. See https://github.com/python/mypy/issues/8584 for a decent entry point with more breadcrumbs on the various behaviors that contribute to this subtle difference. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Tested-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-23-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: move mypy.ini into setup.cfgJohn Snow1-0/+5
mypy supports reading its configuration values from a central project configuration file; do so. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-22-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add excluded dirs to flake8 configJohn Snow1-0/+2
Instruct flake8 to avoid certain well-known directories created by python tooling that it ought not check. Note that at-present, nothing actually creates a ".venv" directory; but it is in such widespread usage as a de-facto location for a developer's virtual environment that it should be excluded anyway. A forthcoming commit canonizes this with a "make venv" command. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-20-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: move flake8 config to setup.cfgJohn Snow1-0/+3
Update the comment concerning the flake8 exception to match commit 42c0dd12, whose commit message stated: A note on the flake8 exception: flake8 will warn on *any* bare except, but pylint's is context-aware and will suppress the warning if you re-raise the exception. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-19-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: move pylintrc into setup.cfgJohn Snow1-0/+29
Delete the empty settings now that it's sharing a home with settings for other tools. pylint can now be run from this folder as "pylint qemu". Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Tested-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-17-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add VERSION fileJohn Snow1-0/+1
Python infrastructure as it exists today is not capable reliably of single-sourcing a package version from a parent directory. The authors of pip are working to correct this, but as of today this is not possible. The problem is that when using pip to build and install a python package, it copies files over to a temporary directory and performs its build there. This loses access to any information in the parent directory, including git itself. Further, Python versions have a standard (PEP 440) that may or may not follow QEMU's versioning. In general, it does; but naturally QEMU does not follow PEP 440. To avoid any automatically-generated conflict, a manual version file is preferred. I am proposing: - Python tooling follows the QEMU version, indirectly, but with a major version of 0 to indicate that the API is not expected to be stable. This would mean version 0.5.2.0, 0.5.1.1, 0.5.3.0, etc. - In the event that a Python package needs to be updated independently of the QEMU version, a pre-release alpha version should be preferred, but *only* after inclusion to the qemu development or stable branches. e.g. 0.5.2.0a1, 0.5.2.0a2, and so on should be preferred prior to 5.2.0's release. - The Python core tooling makes absolutely no version compatibility checks or constraints. It *may* work with releases of QEMU from the past or future, but it is not required to. i.e., "qemu.machine" will, for now, remain in lock-step with QEMU. - We reserve the right to split the qemu package into independently versioned subpackages at a later date. This might allow for us to begin versioning QMP independently from QEMU at a later date, if we so choose. Implement this versioning scheme by adding a VERSION file and setting it to 0.6.0.0a1. Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-12-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
2021-06-01python: add qemu package installerJohn Snow1-0/+22
Add setup.cfg and setup.py, necessary for installing a package via pip. Add a ReST document (PACKAGE.rst) explaining the basics of what this package is for and who to contact for more information. This document will be used as the landing page for the package on PyPI. List the subpackages we intend to package by name instead of using find_namespace because find_namespace will naively also packages tests, things it finds in the dist/ folder, etc. I could not figure out how to modify this behavior; adding allow/deny lists to setuptools kept changing the packaged hierarchy. This works, roll with it. I am not yet using a pyproject.toml style package manifest, because "editable" installs are not defined (yet?) by PEP-517/518. I consider editable installs crucial for development, though they have (apparently) always been somewhat poorly defined. Pip now (19.2 and later) now supports editable installs for projects using pyproject.toml manifests, but might require the use of the --no-use-pep517 flag, which somewhat defeats the point. Full support for setup.py-less editable installs was not introduced until pip 21.1.1: https://github.com/pypa/pip/pull/9547/commits/7a95720e796a5e56481c1cc20b6ce6249c50f357 For now, while the dust settles, stick with the de-facto setup.py/setup.cfg combination supported by setuptools. It will be worth re-evaluating this point again in the future when our supported build platforms all ship a fairly modern pip. Additional reading on this matter: https://github.com/pypa/packaging-problems/issues/256 https://github.com/pypa/pip/issues/6334 https://github.com/pypa/pip/issues/6375 https://github.com/pypa/pip/issues/6434 https://github.com/pypa/pip/issues/6438 Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-id: 20210527211715.394144-11-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
generated by cgit v1.1 at 2024-12-26 16:31:10 +0000