Parsing of dependencies from different build systems about pyscan HOT 11 CLOSED

can you show me the pyproject.toml that pyscan detects? like the content inside?

from pyscan.

Oh, does this imply that only projects with a full pyproject.toml are supported?

I am using setuptools with setup.py and setup.cfg and the pyproject.toml only for configuring the build backend a la...

[build-system]
requires = ["setuptools>=46.4.0", "wheel"]
build-backend = "setuptools.build_meta"

e.g. https://github.com/jugmac00/flask-reuploaded

It would be great to have a helpful error message 👍

from pyscan.

I see. Pyscan currently looks for the [dependencies] table on a pyproject.toml which seems to be the common way to convey dependencies, I'm not sure how exactly setuptools differs in specifying deps but this certainly seems interesting enough to be added support for.

from pyscan.

https://peps.python.org/pep-0631/

Here's the PEP from which the parser for pyproject.toml is partially based on.

from pyscan.

the common way to convey dependencies

I would not call it the "common way" - maybe it is the suggested way, but it is certainly not followed by all packaging tools.

You need to know that the lowest common denominator is that projects configure the build backend in the pyproject.toml, and from here on, it entirely depends on the build system how meta data is configured.

• The currently probably still most widely used tool is setuptools, which has even its own configuration files - ie the config lives outside the pyproject.toml.
• Poetry uses pyproject.toml, but stores the dependencies in tool.poetry.dependencies (and other keys), see https://python-poetry.org/docs/managing-dependencies/
• Tools following your idea are probably hatch and flit, maybe others.

So, way to go :-)

P.S.: It is even not mandatory that Python projects use a pyproject.toml.

from pyscan.

I see. I was under the assumption that the PEP would be a little bit more popular than i thought. Its very weird that the build tools don't follow the PEP and each seems to have its own way of doing it, though. Looks like expanding the parsing of pyproject.toml is something that needs to be done, glad you pointed it out!

from pyscan.

Python exists for 30+ years, the pep 621 (which superseded the one you mentioned) was only accepted at the end of 2020 (and even only as provisional, see https://discuss.python.org/t/pep-621-round-3/5472/109 ) - so it will take time until most package managers will follow that, and probably a good part of Python projects won't update to use a modern package manager for a very long time.

from pyscan.

So support for the setuptools way of dependency spec in pyproject.toml is underway. Do you have any suggestions for other build systems which pyscan should support parsing from? My knowledge regarding them is limited

from pyscan.

The most common ones I encounter are:

• setuptools
• poetry
• hatch
• flit
• pdm

from pyscan.

great, pyscan should be able to support them by the release of next version, thanks

from pyscan.

Looking at https://setuptools.pypa.io/en/latest/userguide/dependency_management.html#declaring-required-dependency

Looks like setuptools does follow the way pyscan scans for dependencies, but since you're using setup.py like in flask-reuploaded all the dependency spec goes into install_requires, so pyscan would need to implement a way to parse that as well. Looks like setup.py needs its own parse implementation.

from pyscan.