[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 zooko):

 Dear Glyph: I'm so glad to have your attention on this issue. I hope you
 feel sufficiently rewarded for the time you're putting into this that you
 keep coming back for more.

 I don't have a response to most of this material at this point, but I just
 want to explain "what is the use case" that Glyph was asking about, when
 he wrote "I am trying to understand the desired user experience outlined
 on this ticket." in comment:17.

 There are at least two use-cases: developer and end-user. The one that I
 have been feeling like I am the sole defender of during the last seven
 (!?!) years has the end-user use case. That use case goes like this:

 1. You are a non-developer end-user.
 2. You read [source:trunk/docs/quickstart.rst].
 3. You follow the steps in it.
 4. You have a running tahoe-lafs locally.

 Because of this use-case, an important requirement for me is that changes
 we make do not cause regressions in the above process! If a change causes
 the above process to break, or requires us to add text to
 [source:trunk/docs/quickstart.rst], then that is an important regression
 in my view.

 For example, if a change that we make adds a new dependency, and that new
 dependency has to be manually installed (i.e. it does not get auto-
 installed when you follow `quickstart.rst`), then that fails this test. If
 we make a change and that causes the install process to become different
 on Windows than on Mac OS X, then that fails this test. If we make a
 change and it causes a working, correctly-configured C compiler to become
 a requirement for install, then that fails this test.

 Now, I'm willing to believe that this has been a fool's errand and a waste
 of time all these years. I'm kind of depressed about it, to be honest,
 because I find the alternative of "Tell the user to go find a software
 developer/operating system maintainer that has done this for them" to be
 unsatisfying. (For one reason, because that disempowers those end users by
 making them reliant on that expert, and for another reason, because
 software developers are people too! The software developer that you find
 will have the same problems you had, but just more experience at working-
 around them.)

 But, my point in writing this comment is not to argue that this use case
 is a worthy one, but instead to ''explain'' why we've done so much of what
 we have done over the years, stuff that seems inexplicable if you are
 unaware of this goal of mine.

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