This release is a pre-release and may not be stable for production use.
iw.recipe.subversion
This product is used to download packages from svn and tar them in a directory.
We need some buildout vars:
>>> data_dir = join(test_dir, 'data')
>>> parts_dir = join(data_dir, 'parts')
>>> buildout = {'instance': {'location': test_dir},
... 'buildout': {'directory': test_dir,
... 'install-from-cache': False,
... 'download-cache':False,
... 'parts-directory': parts_dir}}
>>> name = 'svn-packages'
The recipe will checkout the package from his repository and put it in the section. For testing, we need a local repository:
>>> repository = join(test_dir, 'test_repos') >>> if isdir(repository): rmtree(repository) >>> copytree(join(test_dir, 'repos'), repository) >>> if isdir(os.path.join(parts_dir, 'svn-packages')): ... rmtree(os.path.join(parts_dir, 'svn-packages'))
Then, the recipe should work:
>>> options = {
... 'urls':'file:///%s/my_package/trunk my_package' % repository}
>>> from iw.recipe.subversion import Recipe
>>> recipe = Recipe(buildout, name, options)
>>> os.path.join(parts_dir, 'svn-packages') == recipe.install()
True
Ok, we got it:
>>> ls(parts_dir, 'svn-packages') my_package
If a download-cache directory is given, then an archive is created in the specified path:
>>> cache = join(data_dir, 'cache') >>> buildout['buildout']['download-cache'] = cache >>> recipe = Recipe(buildout, name, options) >>> if isdir(cache): rmtree(cache) >>> files = recipe.install() >>> ls(cache) my_package-r4.tar.gz
Ok, now we can work offline. The package will be installed from the cache directory:
>>> rmtree(repository) >>> rmtree(parts_dir) >>> buildout['buildout']['install-from-cache'] = 'true' >>> buildout['buildout']['download-cache'] = cache >>> recipe = Recipe(buildout, name, options) >>> files = recipe.install() >>> ls(parts_dir, 'svn-packages') my_package >>> ls(parts_dir, 'svn-packages', 'my_package') __init__.py README.txt sub
Well, it’s ok for a trunk url. But when working with tagged version, we don’t want to use subversion if we already have an archive:
>>> copytree(join(test_dir, 'repos'), repository)
>>> rmtree(parts_dir)
>>> options = {
... 'urls':'file:///%s/my_package/tags/v1_0_0 my_package' % repository}
>>> buildout['buildout']['install-from-cache'] = 'false'
>>> buildout['buildout']['download-cache'] = cache
>>> recipe = Recipe(buildout, name, options)
At the first time, we need to update and built the archive:
>>> recipe.need_update True >>> files = recipe.install()
But when we have an archive, we don’t need to:
>>> recipe.need_update False
Then we work offline in an online mode:
>>> rmtree(repository) >>> files = recipe.install()
Test update:
>>> recipe.update() is not None True
Metadata
Release files for iw.recipe.subversion 0.1dev-r6587
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| iw.recipe.subversion-0.1dev_r6587-py2.4.egg | Legacy Egg format | - | - | Details for iw.recipe.subversion-0.1dev_r6587-py2.4.egg |
Release files / iw.recipe.subversion-0.1dev_r6587-py2.4.egg
| Download URL | iw.recipe.subversion-0.1dev_r6587-py2.4.egg |
|---|---|
| Size | 32.3 kB |
| Tags | Egg |
|
SHA-256 checksum How to use checksums |
2af6e91e41b9d06997494ecd2e30ce3ad809f5eebbb31fb79a73822074bdb1c8
|
|
BLAKE2b-256 checksum How to use checksums |
1bedba4e6e0d0a2ca369c6d81270d1bede320c7e17c28b61e7108f8a30d0e4eb
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
Security for iw.recipe.subversion 0.1dev-r6587
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.