On Wed, Feb 23, 2011 at 10:04:24PM +0100, Tarek Ziadé wrote: > > > > One way that seems to work is to add this to setup.cfg: > > > > [easy_install] > > allow_hosts: www.example.com > > > > This will break the download by limiting acceptable hosts to bogus ones that > > can't possibly satisfy the requirement. But it's unsatisfying for several > > reasons: > > > > * It's obscure and doesn't really describe what we're trying to do > > ('fixable' > > I suppose by a comment) > > * Requires the Debian packager to add a setup.cfg or modify an existing one > > in > > the upstream package. > > > > Note that I thought this might also work, but it does not afaict: > > > > [easy_install] > > no_deps: true > > Well, if you want to handle all the dependencies for a project > yourself, you can shortcut distribute or setuptools by using the > --single-version-externaly managed option. > > When using this option, the project will be installed by the vanilla > distutils install command. > > Then it's up to you to handle dependencies. That's how pip does, and Fedora > IIRC > What Barry's talking about is slightly different I think. When running python setup.py test, setup.py may download additional modules that should have been specified in the system package (thus the download should never be tried). This occurs before the software is installed anywhere.
For Fedora we deal with this by preventing processes related to the build from making any non-localhost network connnections. That doesn't catch things when a packager is building on their local machine but it does catch things when the package is built on the builders There's two pieces that work on that: 1) The build hosts themselves are configured with a firewall that prevents a lot of packets from leaving the box, and prevent any packets from going to a non-local network. 2) We build in a chroot and part of chroot construction is to create an empty resolv.conf. This prevents DNS lookups from succeeding and controls the automatic downloading among other things. Neither of these are especially well adapted to being run by a casual packager but the second (a chroot with empty resolv.conf) could be done without too much trouble (we have a tool called mock that creates chroots, it was based on a tool called mach which can use apt and might be better for a Debian usage). Both 1 and 2 could be performed on a VM if you can get your packagers to go that far or are dealing with a build system rather than individual packagers. -Toshio
pgpvocOcZe8qP.pgp
Description: PGP signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig