- 02 Apr, 2024 31 commits
-
-
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
-
Julien Muchembled authored
-
Yusei Tahara authored
_install_and_load is slow, using cache saves time when there are many sections.
-
Kazuhiko Shiozaki authored
Introduce a workaround for the shebang line length limitation in zc.buildout.easy_install.
-
Vincent Pelletier authored
Useful when recipes generate non-string values to be reused by other recipes.
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
Add referred parts' hash strings in __buildout_signature__, that invokes rebuild of a part when one of its (recursive) dependencies are modified. Also remove duplicates and sort entries in __buildout_signature__.
-
Julien Muchembled authored
-
Kazuhiko Shiozaki authored
-
Julien Muchembled authored
Also, updating a part does not put it anymore at the end of the list of installed parts, that was making .installed.cfg too big.
-
Kazuhiko Shiozaki authored
In SlapOS, bootstrap is called each time software release is invoked and we do not want to delete develop-eggs directory. This reverts commit 55d76b34.
-
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
Even though such configuration is wrong...
-
Xavier Thompson authored
This test asserts buildout's behavior with regards to download options, and this was changed by the new algorithm for extends. Tests for the new behavior have not been written yet.
-
Xavier Thompson authored
The new algorithm avoids fetching the same extended file more than once and correctly handles overriding values and += and -=: The new algorithm starts as if there was a buildout file containing ``` [buildout] extends = user/defaults.cfg # if it exists buildout.cfg # if it exists command_line_extends.cfg # if passed on the command line ``` The files are then fetched in depth-first-search postorder and fetching child nodes in the order given by the extends directive, ignoring files that have already been fetched. The buildout dicts are then collected in order, and this linearisation is then merged at the end, overriding the first configs collected with the later ones. The first dict in the linearisation is not from a file, but the dict of buildout's (hardcoded) defaults. This is equivalent to acting as though every file that does not extend anything extends these defaults. The first time a file must be downloaded from a url, the linearisation is merged with the configs already collected, and the resulting options are then used to determine the download options for this download, and every subsequent download. This is a break with buildout's current logic for download options. By analogy with classes in Python, we are computing a linearisation of the class hierarchy to determine the method resolution order (MRO). This algorithm is not the same as Python's MRO since Python 2.3 (C3). It could be good to switch to a C3 linearisation like Python.
-
- 21 Mar, 2024 3 commits
-
-
Xavier Thompson authored
This avoids unecessary copies. This is a preparatory step to reimplementing the extends algorithm. It may be that this breaks the extends algorithm as it is currently implemented.
-
Xavier Thompson authored
This avoids unecessary deepcopies. This is a preparatory step to reimplementing the extends algorithm. It may be that this breaks the extends algorithm as it is currently implemented.
-
Xavier Thompson authored
-
- 13 Mar, 2024 2 commits
-
-
Xavier Thompson authored
If zc.buildout or its dependencies have pinned versions that do not match the currently running versions, they are now installed in the local eggs directory from scratch according to the pinned versions. In offline mode this merely ensures that versions that satisfy the requirements are already available. This is the case when the eggs are already installed, or when the running versions are a match to the pinned versions or the absence of a pinned version. If after this matching versions of zc.buildout and its dependencies are not located in the local eggs or develop-eggs directories, they are copied there as was already the case before.
-
Xavier Thompson authored
When generating an environment dict for subprocess calls to pip, os.environ was accidentally modified despite efforts to copy it and modify only the copy, as copy.copy(os.environ) is not enough.
-
- 08 Nov, 2022 2 commits
-
-
Godefroid Chapelle authored
[ci skip]
-
Maurits van Rees authored
-
- 06 Nov, 2022 2 commits
-
-
Godefroid Chapelle authored
[skip ci]
-
Godefroid Chapelle authored
[ci skip]
-