| Name | oldest-supported-numpy JSON |
| Version |
2023.12.12
JSON |
| download |
| home_page | https://github.com/scipy/oldest-supported-numpy |
| Summary | Meta-package that provides the oldest NumPy that supports a given Python version and platform. If wheels for the platform became available on PyPI only for a more recent NumPy version, then that NumPy version is specified. |
| upload_time | 2023-12-12 16:24:07 |
| maintainer | |
| docs_url | None |
| author | Thomas Robitaille |
| requires_python | >=3.7 |
| license | BSD |
| keywords |
|
| VCS |
 |
| bugtrack_url |
|
| requirements |
No requirements were recorded.
|
| Travis-CI |
No Travis.
|
| coveralls test coverage |
No coveralls.
|
.. image:: https://img.shields.io/pypi/v/oldest-supported-numpy
:target: https://pypi.org/project/oldest-supported-numpy/
:alt: PyPI
About
-----
This is a meta-package which can be used in ``pyproject.toml`` files
to automatically provide as a build-time dependency the oldest version
of NumPy that supports the given Python version and platform. In case
of platforms for which NumPy has prebuilt wheels, the provided version
also has a prebuilt NumPy wheel.
The reason to use the oldest available NumPy version as a build-time
dependency is because of ABI compatibility. Binaries compiled with old
NumPy versions are binary compatible with newer NumPy versions, but
not vice versa. This meta-package exists to make dealing with this
more convenient, without having to duplicate the same list manually in
all packages requiring it.
In other words:
.. code:: toml
[build-system]
requires = [
"wheel",
"setuptools",
"numpy==1.13.3; python_version=='3.5'",
"numpy==1.13.3; python_version=='3.6'",
"numpy==1.14.5; python_version=='3.7'",
# more numpy requirements...
]
can be replaced by:
.. code:: toml
[build-system]
requires = ["wheel", "setuptools", "oldest-supported-numpy"]
And as new Python versions are released, the ``pyproject.toml`` file does not
need to be updated.
Q&A
---
Why define the NumPy pinnings using ``install_requires`` in this repository?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The NumPy version pinnings are defined inside the ``setup.cfg`` file as
``install_requires`` dependencies, rather than as build-time dependencies
inside ``pyproject.toml``. This is deliberate, since NumPy is not actually
required to build wheels of **oldest-supported-numpy**. What we need here
is to make sure that when **oldest-supported-numpy** is installed into
the build environment of a package using it, NumPy gets installed too
as a **runtime** dependency inside the build environment.
Another way to think about this is that since we only publish (universal)
wheels of **oldest-supported-numpy**, the wheel contains no ``pyproject.toml``,
``setup.cfg``, or ``setup.py`` code - it only contains metadata including
dependencies which get installed by pip when **oldest-supported-numpy** is
installed.
Can I use this if my package requires a recent version of NumPy?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In many cases, even though your package may require a version of
NumPy that is more recent than the pinned versions here, this
is often a runtime requirement, i.e. for running (rather than
building) your package. In many cases, unless you use recent
features of the NumPy C API, you will still be able to build your
package with an older version of NumPy and therefore you will still
be able to use **oldest-supported-numpy**. You can still impose a
more recent NumPy requirement in ``install_requires``
What if a bug in NumPy that affects me is fixed only in a newer release?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If **oldest-supported-numpy** pins a ``numpy`` version that is broken for
everyone using a certain OS/platform/interpreter combination, we can update the
``==`` pin to a newer release. In general, building against a newer *bugfix*
release (i.e., a higher ``Y`` value for a ``1.X.Y`` version number) is safe to
do. Newer minor versions will likely not be ABI-compatible, so are much more
difficult to change. If a bug only affects some uses cases (e.g., versions ``<
1.20.3`` don't work on Windows when using ``f2py``), the pin cannot be updated
because it will affect backwards compatibility of **oldest-supported-numpy**.
In that case, it is recommended that you add the needed constraint directly
in your own ``pyproject.toml`` file. For example:
.. code:: toml
[build-system]
requires = [
"wheel",
"numpy==1.19.0; python_version<='3.8' and platform_system=='Windows' and platform_python_implementation != 'PyPy'",
"oldest-supported-numpy; python_version>'3.8' or platform_system!='Windows' or platform_python_implementation == 'PyPy'",
# more requirements (if needed) ...
]
Note that when you do this, it is important to ensure the conditions are such
that there is exactly one pin possible for a given platform configuration.
Otherwise your build will fail or ``pip`` may refuse to install your package
*only* on that configuration (so you likely won't see it in CI).
The **oldest-supported-numpy** repository contains tests, so for safety you
may want to implement your constraints in its ``setup.cfg`` and run the
tests with ``pytest`` to validate those constraints.
Why isn't ``oldest-supported-numpy`` available for Conda, Homebrew, Debian, etc.?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``pyproject.toml`` format is specific to PyPI. Other packaging systems have
their own metadata formats and ways of specifying dependencies. Typically they
don't need anything like **oldest-supported-numpy** because either (a) they ship
only a single NumPy version for a given release (typically the case for Linux
distros and Homebrew), or (b) they have a more explicit way of managing ABI
compatibility (see for example conda-forge's ``pin_compatible`` feature:
https://conda-forge.org/docs/maintainer/knowledge_base.html#linking-numpy).
What about having a catchier name for this package?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The current name is not very catchy as package names go, but it
is very descriptive. This package is only meant to be used in
``pyproject.toml`` files for defining build-time dependencies,
so it's more important to have a descriptive than a catchy name!
What if I think that one of the pinnings is wrong or out of date?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please feel free to `open an issue <https://github.com/scipy/oldest-supported-numpy/issues/new>`_
or a pull request if you think something is wrong or could be improved!
Raw data
{
"_id": null,
"home_page": "https://github.com/scipy/oldest-supported-numpy",
"name": "oldest-supported-numpy",
"maintainer": "",
"docs_url": null,
"requires_python": ">=3.7",
"maintainer_email": "",
"keywords": "",
"author": "Thomas Robitaille",
"author_email": "thomas.robitaille@gmail.com",
"download_url": "https://files.pythonhosted.org/packages/1d/1f/c2a4154830ae702908a969ff8914cb8268a1820327a46e177033c620ea3e/oldest-supported-numpy-2023.12.12.tar.gz",
"platform": null,
"description": ".. image:: https://img.shields.io/pypi/v/oldest-supported-numpy\n :target: https://pypi.org/project/oldest-supported-numpy/\n :alt: PyPI\n\nAbout\n-----\n\nThis is a meta-package which can be used in ``pyproject.toml`` files\nto automatically provide as a build-time dependency the oldest version\nof NumPy that supports the given Python version and platform. In case\nof platforms for which NumPy has prebuilt wheels, the provided version\nalso has a prebuilt NumPy wheel.\n\nThe reason to use the oldest available NumPy version as a build-time\ndependency is because of ABI compatibility. Binaries compiled with old\nNumPy versions are binary compatible with newer NumPy versions, but\nnot vice versa. This meta-package exists to make dealing with this\nmore convenient, without having to duplicate the same list manually in\nall packages requiring it.\n\nIn other words:\n\n.. code:: toml\n\n [build-system]\n requires = [\n \"wheel\",\n \"setuptools\",\n \"numpy==1.13.3; python_version=='3.5'\",\n \"numpy==1.13.3; python_version=='3.6'\",\n \"numpy==1.14.5; python_version=='3.7'\",\n # more numpy requirements...\n ]\n\ncan be replaced by:\n\n.. code:: toml\n\n [build-system]\n requires = [\"wheel\", \"setuptools\", \"oldest-supported-numpy\"]\n\nAnd as new Python versions are released, the ``pyproject.toml`` file does not\nneed to be updated.\n\nQ&A\n---\n\nWhy define the NumPy pinnings using ``install_requires`` in this repository?\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe NumPy version pinnings are defined inside the ``setup.cfg`` file as\n``install_requires`` dependencies, rather than as build-time dependencies\ninside ``pyproject.toml``. This is deliberate, since NumPy is not actually\nrequired to build wheels of **oldest-supported-numpy**. What we need here\nis to make sure that when **oldest-supported-numpy** is installed into\nthe build environment of a package using it, NumPy gets installed too\nas a **runtime** dependency inside the build environment.\n\nAnother way to think about this is that since we only publish (universal)\nwheels of **oldest-supported-numpy**, the wheel contains no ``pyproject.toml``,\n``setup.cfg``, or ``setup.py`` code - it only contains metadata including\ndependencies which get installed by pip when **oldest-supported-numpy** is\ninstalled.\n\nCan I use this if my package requires a recent version of NumPy?\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nIn many cases, even though your package may require a version of\nNumPy that is more recent than the pinned versions here, this\nis often a runtime requirement, i.e. for running (rather than\nbuilding) your package. In many cases, unless you use recent\nfeatures of the NumPy C API, you will still be able to build your\npackage with an older version of NumPy and therefore you will still\nbe able to use **oldest-supported-numpy**. You can still impose a\nmore recent NumPy requirement in ``install_requires``\n\nWhat if a bug in NumPy that affects me is fixed only in a newer release?\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nIf **oldest-supported-numpy** pins a ``numpy`` version that is broken for\neveryone using a certain OS/platform/interpreter combination, we can update the\n``==`` pin to a newer release. In general, building against a newer *bugfix*\nrelease (i.e., a higher ``Y`` value for a ``1.X.Y`` version number) is safe to\ndo. Newer minor versions will likely not be ABI-compatible, so are much more\ndifficult to change. If a bug only affects some uses cases (e.g., versions ``<\n1.20.3`` don't work on Windows when using ``f2py``), the pin cannot be updated\nbecause it will affect backwards compatibility of **oldest-supported-numpy**.\nIn that case, it is recommended that you add the needed constraint directly\nin your own ``pyproject.toml`` file. For example:\n\n.. code:: toml\n\n [build-system]\n requires = [\n \"wheel\",\n \"numpy==1.19.0; python_version<='3.8' and platform_system=='Windows' and platform_python_implementation != 'PyPy'\",\n \"oldest-supported-numpy; python_version>'3.8' or platform_system!='Windows' or platform_python_implementation == 'PyPy'\",\n # more requirements (if needed) ...\n ]\n\nNote that when you do this, it is important to ensure the conditions are such\nthat there is exactly one pin possible for a given platform configuration.\nOtherwise your build will fail or ``pip`` may refuse to install your package\n*only* on that configuration (so you likely won't see it in CI).\nThe **oldest-supported-numpy** repository contains tests, so for safety you\nmay want to implement your constraints in its ``setup.cfg`` and run the\ntests with ``pytest`` to validate those constraints.\n\nWhy isn't ``oldest-supported-numpy`` available for Conda, Homebrew, Debian, etc.?\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe ``pyproject.toml`` format is specific to PyPI. Other packaging systems have\ntheir own metadata formats and ways of specifying dependencies. Typically they\ndon't need anything like **oldest-supported-numpy** because either (a) they ship\nonly a single NumPy version for a given release (typically the case for Linux\ndistros and Homebrew), or (b) they have a more explicit way of managing ABI\ncompatibility (see for example conda-forge's ``pin_compatible`` feature:\nhttps://conda-forge.org/docs/maintainer/knowledge_base.html#linking-numpy).\n\nWhat about having a catchier name for this package?\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe current name is not very catchy as package names go, but it\nis very descriptive. This package is only meant to be used in\n``pyproject.toml`` files for defining build-time dependencies,\nso it's more important to have a descriptive than a catchy name!\n\nWhat if I think that one of the pinnings is wrong or out of date?\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nPlease feel free to `open an issue <https://github.com/scipy/oldest-supported-numpy/issues/new>`_\nor a pull request if you think something is wrong or could be improved!\n",
"bugtrack_url": null,
"license": "BSD",
"summary": "Meta-package that provides the oldest NumPy that supports a given Python version and platform. If wheels for the platform became available on PyPI only for a more recent NumPy version, then that NumPy version is specified.",
"version": "2023.12.12",
"project_urls": {
"Homepage": "https://github.com/scipy/oldest-supported-numpy"
},
"split_keywords": [],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "2ae538361fd00dbf34ccba028d1f4b2459fa8817de5060630c32b9ccf36b7cf9",
"md5": "6bdcdef1c5e0d0e4f27e37f26ff4f930",
"sha256": "21c3e28456e70c323411dd15889b1a828e686672671ef484354db106b47a62e6"
},
"downloads": -1,
"filename": "oldest_supported_numpy-2023.12.12-py3-none-any.whl",
"has_sig": false,
"md5_digest": "6bdcdef1c5e0d0e4f27e37f26ff4f930",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.7",
"size": 4857,
"upload_time": "2023-12-12T16:24:04",
"upload_time_iso_8601": "2023-12-12T16:24:04.393256Z",
"url": "https://files.pythonhosted.org/packages/2a/e5/38361fd00dbf34ccba028d1f4b2459fa8817de5060630c32b9ccf36b7cf9/oldest_supported_numpy-2023.12.12-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "1d1fc2a4154830ae702908a969ff8914cb8268a1820327a46e177033c620ea3e",
"md5": "97e224d8190fb476b82d8d0587cde56b",
"sha256": "1175ba86099f62c28adced7f89eb2e37640d545a14db89ab86c4d66c43dbe113"
},
"downloads": -1,
"filename": "oldest-supported-numpy-2023.12.12.tar.gz",
"has_sig": false,
"md5_digest": "97e224d8190fb476b82d8d0587cde56b",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.7",
"size": 5235,
"upload_time": "2023-12-12T16:24:07",
"upload_time_iso_8601": "2023-12-12T16:24:07.185311Z",
"url": "https://files.pythonhosted.org/packages/1d/1f/c2a4154830ae702908a969ff8914cb8268a1820327a46e177033c620ea3e/oldest-supported-numpy-2023.12.12.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-12-12 16:24:07",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "scipy",
"github_project": "oldest-supported-numpy",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"lcname": "oldest-supported-numpy"
}
