Currently we have all our elements and library files in a top-level
directory and install them into
<root>/share/diskimage-builder/[elements|lib] (where root is either /
or the root of a virtualenv).
The problem with this is that editable/development installs (pip -e)
do *not* install data_files. Thus we have no canonical location to
look for elements -- leading to the various odd things we do such as a
whole bunch of guessing at the top of disk-image-create and having a
special test-loader in tests/test_elements.py so we can run python
unit tests on those elements that have it.
data_files is really the wrong thing to use for what are essentially
assets of the program. data_files install works well for things like
config-files, init.d files or dropping documentation files.
By moving the elements under the diskimage_builder package, we always
know where they are relative to where we import from. In fact,
pkg_resources has an api for this which we wrap in the new
diskimage_builder/paths.py helper [1].
We use this helper to find the correct path in the couple of places we
need to find the base-elements dir, and for the paths to import the
library shell functions.
Elements such as svc-map and pkg-map include python unit-tests, which
we do not need tests/test_elements.py to special-case load any more.
They just get found automatically by the normal subunit loader.
I have a follow-on change (I69ca3d26fede0506a6353c077c69f735c8d84d28)
to move disk-image-create to a regular python entry-point.
Unfortunately, this has to move to work with setuptools. You'd think
a symlink under diskimage_builder/[elements|lib] would work, but it
doesn't.
[1] this API handles stuff like getting files out of .zip archive
modules, which we don't do. Essentially for us it's returning
__file__.
Change-Id: I5e3e3c97f385b1a4ff2031a161a55b231895df5b
Pip now supports retries on failure. If setting multiple pypi mirrors a
fallback will not occure until the failures have finished for the first
mirror. This can cause a substantial delay if mirror fallback occurs a
lot.
Change-Id: Iad37a9015a2d5c861a345a111bd1725b965a42d3
We have a good pattern of namespacing env vars with DIB_. Add support
for DIB_PYPI_MIRROR_URL* and maintain backwards compat support.
Change-Id: I434c9d1b14cd571b20754c9ad7cd64c936f8399a
Using only a local filesystem mirror could lead opaque errors.
Print a warning message in this situations.
Change-Id: I5f77151ea928868f4c441e8a1bb2eb0966b21832
Closes-Bug: #1297948
We check python files with dib-lint rather than flake8 which have
conflicting opinions. This means weve been (forcibly) writing non pep8
python.
Also fixing pep8 issues so tests pass.
Change-Id: Idc9db40334f6e15738a7802c06697270df68741c
pypi-mirror creates a separate mirror index for wheels (one per OS
that mirrors are built on). To be able to use it one then needs to be
able to export multiple mirrors for inclusion in pip.conf. As a drive
by I made it possible to disable the use of the pypi.python.org index
without using --offline (as --offline has larger impact).
Change-Id: I3e85a8069b18cafd7eae4cd0591821acc3b5a739
The pypi element is cool, but some folk have local network mirrors
which we should permit them to use.
Change-Id: Ie840ad1184e72b0e01966eee0298cfd6511b6c19
Using a custom pypi mirror can be very convenient, making image builds
substantially faster - because we create multiple virtual
environments we benefit more than single-virtualenv users would.
Change-Id: I997daf1f9477c447e1fb30818aea9e80a49b31a6
