[tahoe-lafs-trac-stream] [tahoe-lafs] #1220: build/install should be able to refrain from getting dependencies

[tahoe-lafs]

#1220: build/install should be able to refrain from getting dependencies
---------------------------+---------------------------------
     Reporter:  gdt        |      Owner:  gdt
         Type:  defect     |     Status:  new
     Priority:  major      |  Milestone:  undecided
    Component:  packaging  |    Version:  1.8.0
   Resolution:             |   Keywords:  setuptools security
Launchpad Bug:             |
---------------------------+---------------------------------

Old description:

> In a managed package system, each program's dependencies are expressed in
> control files and provided before the package builds.  If the package has
> more dependencies than expresssed, the right behavior is failure so that
> this can be fixed, and it is unhelpful to download/install code either
> from included eggs or especially from the net.
>
> There are two parts to this problem.  One is downloading and installing
> things like py-cryptopp.  The other is that tahoe seems to have to need
> modified versions of standard tools and has included eggs.  This kind of
> divergence should be resolved.
>
> I realize that this complaint is perhaps directed at setuptools, but
> tahoe-lafs inherits responsibility.
>
> A reasonable solution would be to have a switch that packaging systems
> can add.
>
> I put this on packaging even though the bug is in tahoe-lafs, not in any
> packaging of it.

New description:

 In a managed package system, each program's dependencies are expressed in
 control files and provided before the package builds.  If the package has
 more dependencies than expresssed, the right behavior is failure so that
 this can be fixed, and it is unhelpful to download/install code either
 from included eggs or especially from the net.

 There are two parts to this problem.  One is downloading and installing
 things like py-cryptopp.  The other is that tahoe seems to have to need
 modified versions of standard tools and has included eggs.  This kind of
 divergence should be resolved.

 I realize that this complaint is perhaps directed at setuptools, but
 tahoe-lafs inherits responsibility.

 A reasonable solution would be to have a switch that packaging systems can
 add.

 I put this on packaging even though the bug is in tahoe-lafs, not in any
 packaging of it.

--

Comment (by zooko):

 The "allow_hosts=None" configuration that Barry Warsaw was using
 (mentioned in comment:25) is documented here:
 * [http://peak.telecommunity.com/DevCenter/EasyInstall#restricting-
 downloads-with-allow-hosts setuptools doc]
 * [http://packages.python.org/distribute/easy_install.html#restricting-
 downloads-with-allow-hosts distribute doc]

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1220#comment:27>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage