[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:           |    Version:  1.8.0
  packaging              |   Keywords:  setuptools security install
   Resolution:           |  packaging pip
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by daira):

 * keywords:  setuptools security => setuptools security install packaging
               pip


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:

 `pip` has [http://www.pip-installer.org/en/latest/usage.html the following
 relevant options]:
 {{{
 -d, --download <dir>

 Download packages into <dir> instead of installing them, regardless of
 what’s already installed.
 --download-cache <dir>

 Cache downloaded packages in <dir>.
 --src <dir>

 Directory to check out editable projects into. The default in a virtualenv
 is “<venv path>/src”. The default for global installs is “<current
 dir>/src”.
 -U, --upgrade

 Upgrade all packages to the newest available version. This process is
 recursive regardless of whether a dependency is already satisfied.
 --force-reinstall

 When upgrading, reinstall all packages even if they are already up-to-
 date.
 -I, --ignore-installed

 Ignore the installed packages (reinstalling instead).
 --no-deps

 Don’t install package dependencies.
 --no-install

 Download and unpack all packages, but don’t actually install them.
 --no-download

 Don’t download any packages, just install the ones already downloaded
 (completes an install run with –no-install).
 }}}

 These seem very comprehensive and useful!

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