- 02 Apr, 2024 40 commits
-
-
Julien Muchembled authored
This retries with the alternate URL in case of HTTPError with the main one. Used by slapos.recipe.build:download* and slapos.recipe.cmmi recipes.
-
Julien Muchembled authored
- Py3: stop using legacy API of urllib.request and fix download of http(s) URLs containing user:passwd@ - Py2: avoid OOM when downloading huge files This is implemented as a method in case we want to make it configurable via [buildout].
-
Julien Muchembled authored
An optimization is to avoid temporary file when possible: a rename (or hard link) is not always possible (different mount points). Another one is to not check md5sum twice when using cache file. Fall-back mode is ignored if an MD5 checksum is given. In case of checksum mismatch for a cached path, remove it and download again, mainly to cover the following cases: - the url content changes and the user updates the checksum - buildout killed while downloading directly to cache (see above optimization) - shutil.copyfile is interrupted
-
Jérome Perrin authored
We want two identical sections at different URL to be able to produce same signature. This feature is useful for slapos.recipe.cmmi's shared parts. This commit may fixup "Support ${:_profile_base_location_}." but is purposefuly kept separate because it concerns parts signatures which are an orthogonal feature.
-
Kazuhiko Shiozaki authored
-
Xavier Thompson authored
-
Xavier Thompson authored
Use a special .pydistutils.cfg in a temporary HOME directory for the duration of the pip wheel run to prevent build dependencies specified in a setup_requires from being installed on the fly without respecting pinned versions.
-
Kazuhiko Shiozaki authored
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
When there is no pinned version for zc.buildout itself, buildout adds a ">=<current-version>" requirement to prevent accidental downgrading. If the current version has a local version label, this produced an invalid version specifier. To fix this, only the public part of the current version is used.
-
Xavier Thompson authored
-
Xavier Thompson authored
-
Xavier Thompson authored
Now that we use `pip wheel` + `Wheel.install_as_egg` to produce genuine eggs, we don't need to workaround the fact that we have not-actually-egg `.egg` bundles anymore. If we still do need to allow for non-eggs being installed in `~/.eggs`, via extensions or others, we should revert this. See https://github.com/buildout/buildout/pull/352
-
Xavier Thompson authored
`pip install <package>` produces a `<package-name>` package folder and a `<package-name>.dist-info` metadata folder, which is another format than eggs. Then buildout bundles both folders into a parent folder `<package.egg>` and tries to act as though it were an egg. Instead, use `pip wheel` to produce a wheel - which `pip install` does internally anyway - and `setuptools.Wheel.install_as_egg` to produce a genuine egg. This is much cleaner: it consistently produces genuine eggs instead of sometimes true eggs, sometimes `.dist-info` bundles depending on whether `pip install` is called or the package was installed from a `.whl` or `.egg` archive directly. The only downside it this requires setuptools >= 38.2.3.
-
Julien Muchembled authored
Before this, += and -= worked well when applied to keys defined in the current section or in a section of the same name inherited from a file extended by the current file, but not to keys inherited from another section using macro extension <=, because <= substitution happens later and all the += and -= are already resolved. e.g.: ``` [macro] a = 1 [part] <= macro a += 2 ``` was equivalent to ``` [part] a = 1 a = 2 ``` instead of ``` [part] a = 1 a += 2 ``` Now a partial and brittle support for this is enabled by postponing += and -= resolution until <= substitution happens when the current section contains a <= extension. But this is not guaranteed: if the current section is overloaded in another file extending the current one, then += and -= resolution will happend then, before <=. A consistent solution would be to unify the implementation of extends= and <= and update sections by taking both into account, instead of updating based only on extends and computing <= later, leading to inconsistencies. This could be achieved e.g. by computing section updates on demand during substitution. Co-authored-by: Xavier Thompson <xavier.thompson@nexedi.com>
-
Julien Muchembled authored
Before this, += and -= worked correctly when applied to a key defined in a file extended by the current file, but not when the key was in the same file. e.g.: ``` [part] a = this case is ``` ``` [buildout] extends = a.cfg [part] a += ok b = this case is b += not-ok ``` Co-authored-by: Xavier Thompson <xavier.thompson@nexedi.com>
-
Xavier Thompson authored
Before this, sys.exit(1) was called to terminate the program directly.
-
Xavier Thompson authored
By default pip installs build dependencies (e.g. setuptools, poetry) in a temporary folder and temporarily adds it to sys.path in order to proceed to build the distribution. But we want all distributions to be installed with buildout and respect pinned versions, so we aim to prevent pip from installing build dependencies. Instead, we will install the build dependencies first and pass them explicitly to zc.recipe.egg via the setup-eggs option. This commit prevents pip from installing the build dependencies listed by the `build-system.requires` key in the pyproject.toml file. It may prevent pip from installing PEP 517 dynamic build dependencies or setuptools' setup_requires dependencies. See https://peps.python.org/pep-0517/#get-requires-for-build-wheel
-
Rafael Monnerat authored
While invoke setup.py certain eggs (like scikit-learn) launch cetain custom builds (for cython) using subprocess and sys.executable. This commit aims to preserve the sys.path over the runs, even if an egg is using subprocess with the same python to build a component of the egg.
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
Now specified patches are automatically applied on required eggs as well.
-
Kazuhiko Shiozaki authored
- Support on the fly patches in zc.recipe.egg by ``EGGNAME-patches``, ``EGGNAME-patch-options``, ``EGGNAME-patch-binary`` (or ``patch-binary``) and ``EGGNAME-patch-revision`` options. - Support on the fly patches in zc.recipe.egg:custom by ``patches``, ``patch-options``, ``patch-binary`` and ``patch-revision`` options. (options ``EGGNAME-*`` are also supported as well).
-
Kirill Smelkov authored
Currently only zc.recipe.egg:custom supports setting environment variables, and zc.recipe.egg:develop does not. My motivation for allowing setting environment in :develop is wendelin.core https://lab.nexedi.cn/nexedi/slapos/blob/b5faab3b/component/wendelin.core/buildout.cfg There we have [wendelin.core] part which installs released egg from pypi, and [wendelin.core-dev] part which installs wendelin.core from its latest git version via zc.recipe.egg:develop . The problem is, wendelin.core for setup.py to work, needs git available, and with slapos we usually don't have git available on base system, so we build it by our own and do something like [wendelin.core-dev] recipe = zc.recipe.egg:develop environment = wendelin.core-dev-env [wendelin.core-dev-env] # wendelin.core-dev needs git to build PATH = ${git:location}/bin:%(PATH)s and the problem is environment does not currently work for zc.recipe.egg:develop, and thus git is not found -> build fails. ~~~~ In order to support environment in :develop, we just move environment setting/restoring bits from Custom to Base, and provide Base.install() which uses this bits. Custom & Develop .install() becomes ._install() which gets hooked into Base.install() . I've tested the patch only manually, because currently automated tests are broken in a lot of places for slapos.buildout and zc.recipe.egg . /cc @kazuhiko, @Tyagov
-
Kazuhiko Shiozaki authored
-
Julien Muchembled authored
To be dropped once all buildout in the wild are able to upgrade to a version that supports new names in expression of conditional sections (see previous commit).
-
Julien Muchembled authored
Adding new names for expression is currently not possible because buildout aborts before it tries to upgrade (in-place or bootstrap).
-
Julien Muchembled authored
For example, existing values were not enough to distinguish 'arm-linux-gnueabi' from 'arm-linux-gnueabihf'. The 'multiarch' value is the output of $CC -dumpmachine where CC defaults to 'gcc'. See also https://wiki.debian.org/Multiarch/Tuples
-
Julien Muchembled authored
(changed option or missing path) Sometimes, most parts are reinstalled for a reason that the user didn't think about and it can take time to understand why. Explaining for all parts would be too verbose and useless because many are reinstalled just because their dependencies changed.
-
Julien Muchembled authored
-
Julien Muchembled authored
Egg is installed from wheel when the requested version ends with :whl
-
Thomas Gambier authored
Reuse more code from slapos.core to support case of parent directory not writable.
-
Jérome Perrin authored
When recipes mutate the options, we should not allow invalid syntax otherwise it gets written in .installed.cfg and generate invalid configparser syntax.
-
Jérome Perrin authored
When recipe mutate options, options values are written to .installed.cfg without escaping buildout substitution syntax, so if a recipe sets an option value that could be interpreted as a buildout substitution, it is written as is in .installed.cfg. This can be a problem if options read from _read_installed_part_options are accessed, like it's the case with slapos patched buildout which saves installed options after an error with part installation or after each part installation when running in verbose mode.
-
Jérome Perrin authored
python ZipFile module does not support updating an entry in place, instead make a new zip file and copy all entries.
-
Julien Muchembled authored
-
Julien Muchembled authored
This is useful when using OS Python & eggs. Useless for SlapOS.
-
Julien Muchembled authored
To set a default requirement for not-yet processed parts
-
Julien Muchembled authored
The version of Python should not affect the behaviour of a recipe. Anyway, it was already ignored for DEVELOP_DIST eggs. This makes the slapos mechanism to share parts more efficient. And with the upcoming changes in buildout & slapos.recipe.cmmi, there would be no way for the slapos.reboostrap extension to prevent everything from being rebuilt when reboostrapping to a different version of Python, if bootstrap parts are shared. The monkey-patch by slapos.reboostrap now becomes useless.
-
Julien Muchembled authored
-