buildout.sendpickedversions
This package is based on buildout.dumppickedversions and its purpose is to gather the package name and version information from buildout. The main difference with buildout.dumppickedversions is that instead of displaying picked versions, or dumping everything to a file, we’ll send package information to a predefined URL.
Original use case is that there is Whiskers server on the other end which stores the data. There’s nothing special about the data, so other end can just as well be anything that can handle json.
Configuration
To use buildout.sendpickedversions with buildout your buildout.cfg should have buildout.sendpickedversions in you extensions-line and following fields configured:
- buildoutname
This is the name of the buildout. Whiskers uses this information to create new buildout object with the package data. If name is not set we use default ‘dummy_buildout’ as a name.
- whiskers-url
This is the url to whiskers server. As stated above, you can use here anything that can just eat the json-data we’re sending. If you leave this empty or don’t set at all buildout.sendpickedversions just displays the data dict.
Example
Here’s small example configuration.
[buildout] extensions = buildout.sendpickedversions buildoutname = test whiskers-url = http://localhost:6543/buildouts/add parts = nose [nose] recipe = zc.recipe.egg eggs = nose
Above example configuration assumes you have Whiskers server running locally on port 6543. If you run buildout it will install nose normally to your buildout environment and after everything is ready it will try to send following data in json-format to localhost:6543/buildouts/add URL:
{"buildoutname": "test",
"packages": [
{"version": "0.6.24", "name": "distribute"},
{"version": "1.18", "name": "mr.developer"},
{"version": "1.1.2", "name": "nose"},
{"required_by": ["mr.developer 1.18"], "version": "1.5.2", "name": "zc.buildout"},
{"version": "1.3.2", "name": "zc.recipe.egg"}
]
}
Thanks
Code is mainly based to Mustapha Benali’s buildout.dumppickedversions. This buildout extension has probably saved thousands of buildouts from nasty version conflicts or total havoc. Huge thanks!
Changelog
0.3 (2012-10-11)
Performance optimizations (ported from zc.buildout).
0.2 (2011-10-16)
Sends data urlencoded.
0.1 (2011-10-16)
Initial import
Metadata
Release files for buildout.sendpickedversions 0.3
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| buildout.sendpickedversions-0.3.zip | 15.5 kB | Without provenance | Details |
Release files / buildout.sendpickedversions-0.3.zip
| Download URL | buildout.sendpickedversions-0.3.zip |
|---|---|
| Size | 15.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
c336466ecfb25b1d323e68c49e582013d838e24a92b9d96e689bdc934c8312d9
|
|
BLAKE2b-256 checksum How to use checksums |
1b1b854b64b652292e0c90e1c0f200b70534096f8b571cf41d25f47d2950536c
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
Security for buildout.sendpickedversions 0.3
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.