*******
enscons
*******
Build Python packages with SCons.
Enscons is a Python packaging tool based on `SCons <http://scons.org/>`_. It builds pip-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than distutils. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system.
Enscons helps you to build sdists that can be automatically built by pip, and wheels that are independent of enscons.
About this fork
---------------
This fork adds the following features to plain enscons:
* optionally name SConstruct files enscons.py
* possibility to pass --config-settings of the form 'option=value' into SCons ARGUMENTS
* possibility to have smaller SConstructs with the help of enscons.helper module (remove boilerplate code)
* experimentally support pyarmor
What does enscons provide?
--------------------------
Enscons provides a small amount of code to generate wheels, do development installs, generate egg-info and dist-info metadata, do basic conversion of setup.py to pyproject.toml and SConstruct, and configure SCons' compilers with the flags distutils would use to compile C extensions.
Enscons implements a `PEP 518 <https://www.python.org/dev/peps/pep-0518/>`_ build backend, and a setup.py shim that can be used for `pip install -e .`
Enscons provides code to translate from the arguments pip and tox send to setup.py to something SCons can use, and then executes the SConstruct, the SCons analog to a Makefile.
Why might you want to use enscons?
----------------------------------
Enscons is most useful if you want to use SCons. SCons has superpowers that distutils doesn't. You might want to use enscons if:
* You can never remember how to write MANIFEST.in.
Enscons does not use MANIFEST.in. Instead, SCons automatically knows which files are source based on which files you've told it to build or install. You build this list with straightforward ``glob()``, or any Python code.
* You would like to include generated files in your sdist.
All Python sdists include generated PKG-INFO metadata, but sometimes it is useful to include other generated files, such as generated C extension code, in a sdist. Once SCons knows how to build your file, just appending it to the list of sources will cause it to be automatically rebuilt and included in your source archive.
* You sometimes forget to clean your build directory.
SCons does not care if there are extra files in your build directory. Its dependency tracking technology knows exactly the files you meant to build; if you build wheels for PyPy and CPython (different C extension filenames) without cleaning the build directory, it will only include the correct extensions in each wheel.
* You prefer to build only when necessary.
SCons only rebuilds your C extensions, sdists, and wheels when their dependencies have changed.
* You need to extend distutils.
The most compelling reason to use enscons is if distutils (or setuptools, which shares its architecture) is not meeting your needs. Distutils' fundamental subclass-based architecture makes it notoriously difficult to extend, and any distutils extension must be debugged against several versions of Python, setuptools, and any other distutils extension your end users might be using.
In SCons, adding a simple compiler is practically a one-liner. If your project needs to use code generation or invoke any kind of compiler or build chain that is not supported by distutils, it is probably easier to switch than to extend distutils.
* You would like to develop your own distutils replacement.
Enscons is well under 1,000 lines of code, but implements ``wheel``, ``setup.py``, ``setup.py develop``, and other tricky bits that can seem like magic. The important parts of distutils are simple. Enscons might be a useful reference for someone who would like to implement the same features on top of a different general-purpose build system.
Using enscons
=============
Install enscons with ``pip install enscons``.
If you are starting from an existing project, try running ``python -m enscons.setup2toml`` next to your ``setup.py`` to convert. It will create a ``pyproject.toml`` and ``SConstruct`` that should serve as a good starting point. It can convert simple pure-Python projects with only ``*.py`` but the ``SConstruct`` will require some tweaking for projects with non-Python files or C extensions.
Build the project by running ``python -m SCons``.
If you are not starting from an existing ``setup.py``, get enscons' source code, and copy ``pyproject.toml``, ``SConstruct``, and ``setup.py`` into your own project.
Edit ``pyproject.toml`` with your own metadata keys in `PEP 621 <https://www.python.org/dev/peps/pep-0621/>`_ format.
Enscons will use those keys to generate the static metadata files (``PKG-INFO`` and ``METADATA``).
In addition to PEP 621, some ``setup.py``-style keys are recognized: ``description_file`` (superseded by ``readme``), ``url``, ``author`` and ``author_email`` (superseded by ``authors``), ``license`` as a string, ``keywords`` as a string, ``platform``, ``install_requires`` (superseded by ``dependencies``), ``extras_require`` (superseded by ``optional-dependencies``), and ``src_root``.
Example enscons projects
------------------------
Right now, the best way to learn how enscons works is by example.
* `rsalette <https://github.com/dholth/rsalette/>`_ Simple package with just two modules.
* `cryptacular <https://github.com/dholth/cryptacular/>`_ Has a C extension.
* `pysdl2-cffi <https://github.com/dholth/pysdl2-cffi/>`_ Generates Python and C source code as part of the build, then compiles the generated source.
* `hello-pyrust <https://github.com/dholth/hello-pyrust>`_ An extension using `Rust <https://www.rust-lang.org/>`_ and `cffi <http://cffi.readthedocs.io/en/latest/>`_ instead of C.
* `enscons <https://github.com/dholth/enscons/>`_ Enscons builds itself.
* `nonstdlib <https://github.com/dholth/nonstdlib/>`_ Experimental repackaging of the Python standard library into many wheels.
More about SCons
================
SCons is a general purpose build system. It is pure Python, it can run on both Python 2 and 3, and it has a good community. Very few other build systems meet all of these criteria. These features make SCons a good platform for an experimental Python packaging system.
Raw data
{
"_id": null,
"home_page": "https://github.com/cwiede/enscons",
"name": "enscons-forked",
"maintainer": "",
"docs_url": null,
"requires_python": "",
"maintainer_email": "",
"keywords": "packaging,wheel",
"author": "Christoph Wiedemann",
"author_email": "62332054+cwiede@users.noreply.github.com",
"download_url": "",
"platform": null,
"description": "\n*******\nenscons\n*******\n\nBuild Python packages with SCons.\n\nEnscons is a Python packaging tool based on `SCons <http://scons.org/>`_. It builds pip-compatible source distributions and wheels without using distutils or setuptools, including distributions with C extensions. Enscons has a different architecture and philosophy than distutils. Rather than adding build features to a Python packaging system, enscons adds Python packaging to a general purpose build system.\n\nEnscons helps you to build sdists that can be automatically built by pip, and wheels that are independent of enscons.\n\nAbout this fork\n---------------\n\nThis fork adds the following features to plain enscons:\n\n* optionally name SConstruct files enscons.py \n\n* possibility to pass --config-settings of the form 'option=value' into SCons ARGUMENTS\n\n* possibility to have smaller SConstructs with the help of enscons.helper module (remove boilerplate code)\n\n* experimentally support pyarmor\n\nWhat does enscons provide?\n--------------------------\n\nEnscons provides a small amount of code to generate wheels, do development installs, generate egg-info and dist-info metadata, do basic conversion of setup.py to pyproject.toml and SConstruct, and configure SCons' compilers with the flags distutils would use to compile C extensions. \n\nEnscons implements a `PEP 518 <https://www.python.org/dev/peps/pep-0518/>`_ build backend, and a setup.py shim that can be used for `pip install -e .`\n\nEnscons provides code to translate from the arguments pip and tox send to setup.py to something SCons can use, and then executes the SConstruct, the SCons analog to a Makefile. \n\nWhy might you want to use enscons?\n----------------------------------\n\nEnscons is most useful if you want to use SCons. SCons has superpowers that distutils doesn't. You might want to use enscons if:\n\n* You can never remember how to write MANIFEST.in.\n\n Enscons does not use MANIFEST.in. Instead, SCons automatically knows which files are source based on which files you've told it to build or install. You build this list with straightforward ``glob()``, or any Python code.\n\n* You would like to include generated files in your sdist.\n\n All Python sdists include generated PKG-INFO metadata, but sometimes it is useful to include other generated files, such as generated C extension code, in a sdist. Once SCons knows how to build your file, just appending it to the list of sources will cause it to be automatically rebuilt and included in your source archive.\n\n* You sometimes forget to clean your build directory.\n\n SCons does not care if there are extra files in your build directory. Its dependency tracking technology knows exactly the files you meant to build; if you build wheels for PyPy and CPython (different C extension filenames) without cleaning the build directory, it will only include the correct extensions in each wheel.\n\n* You prefer to build only when necessary.\n\n SCons only rebuilds your C extensions, sdists, and wheels when their dependencies have changed.\n\n* You need to extend distutils.\n\n The most compelling reason to use enscons is if distutils (or setuptools, which shares its architecture) is not meeting your needs. Distutils' fundamental subclass-based architecture makes it notoriously difficult to extend, and any distutils extension must be debugged against several versions of Python, setuptools, and any other distutils extension your end users might be using.\n \n In SCons, adding a simple compiler is practically a one-liner. If your project needs to use code generation or invoke any kind of compiler or build chain that is not supported by distutils, it is probably easier to switch than to extend distutils.\n\n\n* You would like to develop your own distutils replacement.\n\n Enscons is well under 1,000 lines of code, but implements ``wheel``, ``setup.py``, ``setup.py develop``, and other tricky bits that can seem like magic. The important parts of distutils are simple. Enscons might be a useful reference for someone who would like to implement the same features on top of a different general-purpose build system.\n\nUsing enscons\n=============\n\nInstall enscons with ``pip install enscons``.\n\nIf you are starting from an existing project, try running ``python -m enscons.setup2toml`` next to your ``setup.py`` to convert. It will create a ``pyproject.toml`` and ``SConstruct`` that should serve as a good starting point. It can convert simple pure-Python projects with only ``*.py`` but the ``SConstruct`` will require some tweaking for projects with non-Python files or C extensions.\n\nBuild the project by running ``python -m SCons``.\n\nIf you are not starting from an existing ``setup.py``, get enscons' source code, and copy ``pyproject.toml``, ``SConstruct``, and ``setup.py`` into your own project.\n\nEdit ``pyproject.toml`` with your own metadata keys in `PEP 621 <https://www.python.org/dev/peps/pep-0621/>`_ format.\nEnscons will use those keys to generate the static metadata files (``PKG-INFO`` and ``METADATA``).\nIn addition to PEP 621, some ``setup.py``-style keys are recognized: ``description_file`` (superseded by ``readme``), ``url``, ``author`` and ``author_email`` (superseded by ``authors``), ``license`` as a string, ``keywords`` as a string, ``platform``, ``install_requires`` (superseded by ``dependencies``), ``extras_require`` (superseded by ``optional-dependencies``), and ``src_root``.\n\nExample enscons projects\n------------------------\n\nRight now, the best way to learn how enscons works is by example.\n\n* `rsalette <https://github.com/dholth/rsalette/>`_ Simple package with just two modules.\n* `cryptacular <https://github.com/dholth/cryptacular/>`_ Has a C extension.\n* `pysdl2-cffi <https://github.com/dholth/pysdl2-cffi/>`_ Generates Python and C source code as part of the build, then compiles the generated source.\n* `hello-pyrust <https://github.com/dholth/hello-pyrust>`_ An extension using `Rust <https://www.rust-lang.org/>`_ and `cffi <http://cffi.readthedocs.io/en/latest/>`_ instead of C.\n* `enscons <https://github.com/dholth/enscons/>`_ Enscons builds itself.\n* `nonstdlib <https://github.com/dholth/nonstdlib/>`_ Experimental repackaging of the Python standard library into many wheels.\n\n\nMore about SCons\n================\n\nSCons is a general purpose build system. It is pure Python, it can run on both Python 2 and 3, and it has a good community. Very few other build systems meet all of these criteria. These features make SCons a good platform for an experimental Python packaging system.\n",
"bugtrack_url": null,
"license": "MIT",
"summary": "Tools for building Python packages with SCons (forked for providing some useful features)",
"version": "0.28.0",
"project_urls": {
"Homepage": "https://github.com/cwiede/enscons"
},
"split_keywords": [
"packaging",
"wheel"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "81b4970236f66137a8049de914004ca83438f5d64493d430b9353d8b3654eeb8",
"md5": "285a21cec9aee58f10cdd786fd46479d",
"sha256": "0fb9a6d3c07aff803f2e65f4a56665e03d050ba04fcd50861b7dc40a7c6ce065"
},
"downloads": -1,
"filename": "enscons_forked-0.28.0-py2.py3-none-any.whl",
"has_sig": false,
"md5_digest": "285a21cec9aee58f10cdd786fd46479d",
"packagetype": "bdist_wheel",
"python_version": "py2.py3",
"requires_python": null,
"size": 25461,
"upload_time": "2024-02-06T15:27:17",
"upload_time_iso_8601": "2024-02-06T15:27:17.025067Z",
"url": "https://files.pythonhosted.org/packages/81/b4/970236f66137a8049de914004ca83438f5d64493d430b9353d8b3654eeb8/enscons_forked-0.28.0-py2.py3-none-any.whl",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-02-06 15:27:17",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "cwiede",
"github_project": "enscons",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"lcname": "enscons-forked"
}
JSON
