You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can do this in a PR, but I wanted to ask if there were any objections before I get started on this.
As of recently, setup.py has been considered deprecated in favor of a build-system independent format.
Seeing as qiling only uses setuptools anyways, the plan to migrate the package to PEP 518 is to specify only setuptools in the pyproject.toml file, alongside dependencies, license, and other metadata.
This setup would either shrink or remove setup.py entirely; setuptools itself does not support editable installs without a setup.py, but that has a workaround in pip, although this mandates a minimum pip version of 21.3.
The text was updated successfully, but these errors were encountered:
Keeping up to date with the standard is always good, but we have leave some room for slower user adoption (meaning not moving forward too fast). Specifically, this project made a decision to move to Python 3.8 just recently, so we have to make sure this change doesn't break anything.
I can do this in a PR, but I wanted to ask if there were any objections before I get started on this.
As of recently,
setup.py
has been considered deprecated in favor of a build-system independent format.Seeing as qiling only uses
setuptools
anyways, the plan to migrate the package to PEP 518 is to specify onlysetuptools
in thepyproject.toml
file, alongside dependencies, license, and other metadata.This setup would either shrink or remove
setup.py
entirely; setuptools itself does not support editable installs without asetup.py
, but that has a workaround inpip
, although this mandates a minimum pip version of 21.3.The text was updated successfully, but these errors were encountered: