[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2077: pip packaging plan

[Tahoe-LAFS]

#2077: pip packaging plan
---------------------------+--------------------------------------
     Reporter:  daira      |      Owner:
         Type:  defect     |     Status:  new
     Priority:  normal     |  Milestone:  undecided
    Component:  packaging  |    Version:  1.10.0
   Resolution:             |   Keywords:  pip packaging setuptools
Launchpad Bug:             |
---------------------------+--------------------------------------

Comment (by glyph):

 Replying to [comment:28 zooko]:
 > I really don't like a system in which an operating system priest is
 required to intervene between the developers who write the software and
 the users who run it. (Which is different from saying that such
 intercessors shouldn't be *possible* or *easy* or whatever.)

 I completely agree.  But, if you want to solve that problem, it's best to
 address it at the source (work on pip, setuptools, apt, etc) than to re-do
 the work in each package.  Each software package like Tahoe having its own
 build idioms makes the situation ''worse'' because it increases the
 surface area of expertise that the anointed intercessors have and the
 plebs don't, increasing the need for them (us?).

 There's a deeper philosophical argument here, too, which we should really
 discuss over some very strong beverage, either caffeinated or alcoholic
 :-).

 > I don't see why the continuous integration server shouldn't build a
 package on every commit,

 That sounds like a great idea, and Tahoe should probably have that.
 Twisted kinda does, and although we don't distribute the artifacts that
 are created on each commit, our release manager does distribute various
 artifacts produced by the build system and doesn't build all of them
 directly.

 > and that package shouldn't be executable on every platform.

 The reason that ''one'' package shouldn't be executable on every platform
 is that a "platform" is (more or less by definition) a set of requirements
 for an executable artifact, and different platforms are, well, different.
 Trying to create a combo Mac app / Windows app / iOS app / Red Hat package
 / Debian package / Ubuntu package all at once is just about as silly to
 try to make a program which is valid C, Perl, and Python all at the same
 time.

 > Who's in charge of computing technology, anyway? They're fucking up.

 Oops.  It's all of us, right here.  Sorry :-(.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2077#comment:32>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage