- 29 Apr, 2024 4 commits
-
-
Xavier Thompson authored
This option determines what paths zc.buildout will scan for already installed distributions. This defaults to sys.path and can be set to an empty value to enable isolation. The special value 'legacy' yields the previous behavior of scanning specifically the paths of the current zc.buildout distribution and its dependencies.
-
Xavier Thompson authored
In bootstrap we potentially copy eggs from the working set to ./eggs. We then reconstruct the same working set using the moved locations. This commits ensures we keep a correct working set order throughout and that we avoid activating unintended dists.
-
Xavier Thompson authored
If a dist in the computed working set is at a location shared with other dists - such as site-packages - then when generating scripts these other packages may overshadow the next items on the sys.path and result in importing a different version than the one installed and intended by buildout. To avert this, a sort of the working set was introduced at various points just before generating a script. However, that sort put the paths referenced from an `.egg-link` in ./develop-eggs first. This is truly problematic because dists from site-packages which are not eggs - e.g. dists installed with pip - can become referenced as `.egg-link` during buildout bootstrap and the sort then causes site-packages to be one of the first items in sys.path. In particular when running buildout bootstrap from a venv in which zc.buildout was installed by pip, if any one of zc.buildout or its dependencies from the venv meets the version requirements, then it can cause the generated bin/buildout to import the dists only from the venv's site-packages, even when some do not meet requirements. To fix this, the sort now puts the dists from `./eggs` first as we know their locations contain only a single dist, and then puts the dists from ./develop-eggs which have locations inside the buildout directory before the others. The previous sort was also activating all the dists from the paths of the already activated dists. Note that this also means that any working set must be manipulated with care in general to avoid activating unintended dists from the locations of the already activated dists.
-
Xavier Thompson authored
Replace `pkg_resources.Environment(ws.entries).best_match(req, ws)` with `ws.find(req)`. The first already starts by calling `ws.find(req)` to attempt to find an already activated dist in the working set, but if none is found it then proceeds to scan through the entries of the environment - i.e. the locations of the directly-requested distributions, `ws.entries` - to activate a dist at these locations if one matches. This is problematic when directly-requested distributions are found in a location shared by multiple dists, such as site-packages: this gives that location precedence over the normal order of locations scanned by easy_install, and can result in undesired versions being chosen over versions available in ./eggs or in ./develop-eggs. The random aspect of this is also problematic, as the order of paths considered will depend on the order of the directly-requested distributions and where they are found.
-
- 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 31 commits
-
-
Godefroid Chapelle authored
[skip ci]
-
Godefroid Chapelle authored
[ci skip]
-
Godefroid Chapelle authored
[ci skip]
-
Godefroid Chapelle authored
[skip ci]
-
Maurits van Rees authored
-
Maurits van Rees authored
For example: `[versions:python_version <= "3.9"]`. Fixes https://github.com/buildout/buildout/issues/621
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
[skip ci]
-
Godefroid Chapelle authored
[skip ci]
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
in 3.11
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
Also update action/checkout version
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
files in subdirs were not managed
-
Godefroid Chapelle authored
in the dev environment
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
-
Godefroid Chapelle authored
-
Jonas Piterek authored
Also fixed virtualenv install under 2.7
-
Jonas Piterek authored
-
- 05 Nov, 2022 1 commit
-
-
Maurits van Rees authored
* Make compatible with pip 22.2+, restoring Requires-Python functionality there. Fixes https://github.com/buildout/buildout/issues/613. Note: we are patching `process_url` from `setuptools`. The existing comment says that this method was copied over from setuptools 46.1.3. I was wondering, so I checked: the method is still the same in latest setuptools. And it is largely unchanged since setuptools 42.0.2. So for that part we should still be compatible with quite a long range of setuptools versions. * process_url patch: must pass cache_link_parsing=False. This fixes test failures: extdemo-1.5 was not found, because the previous index page containing only extdemo-1.4 was cached. We were passing this before to HTMLPage, and still do as a fallback, but I missed that this was also needed in pip 22.2+ for the new IndexContent class.
-