[tahoe-lafs-trac-stream] [tahoe-lafs] #1960: spurious warnings that look a little like errors when building/installing 1.10

[tahoe-lafs]

#1960: spurious warnings that look a little like errors when building/installing
1.10
---------------------------+----------------------------------------------
     Reporter:  daira      |      Owner:  daira
         Type:  defect     |     Status:  closed
     Priority:  minor      |  Milestone:  1.11.0
    Component:  packaging  |    Version:  1.10.0
   Resolution:  fixed      |   Keywords:  warning build install setuptools
Launchpad Bug:             |
---------------------------+----------------------------------------------

Comment (by zooko):

 It looks like the warning message is trying to tell us that we've labeled
 {{{src/allmydata/web/static/css}}} and {{{src/allmydata/web/static}}} as
 "packages" in
 [source:trunk/setup.py?annotate=blame&rev=37c8b733a57dbbc4f9db0b3c8427f4e07994c3fa#L435
 setup.py line 435] and then we've labeled {{{src/allmydata/web/*.xhtml}}},
 {{{src/allmydata/web/static}}}, {{{src/allmydata/web/static/css}}}, and
 {{{src/allmydata/web/static/img}}} as "package data" in
 [source:trunk/setup.py?annotate=blame&rev=37c8b733a57dbbc4f9db0b3c8427f4e07994c3fa#L454
 setup.py line 454].

 This seems probably-wrong in a few ways. First of all,
 {{{src/allmydata/web/static}}} and anything underneath it is not a
 package, since it is not a way to make Python modules importable, and
 should probably not be included in "packages". People sometimes put files
 that they want at runtime like this into "packages" because that's a way
 to get the files included into dists, but it is not a reliable way to make
 those files open'able by our code at run-time, since it is intended only
 for making Python modules importable, not arbitrary files open'able. For
 example, if our app is bundled into a zip file by "bbfreeze" or one of
 those other "single-file-python-app" hacks, then Python modules located in
 such a package would still be importable, but arbitrary files in there
 probably wouldn't be open'able.

 In any case, I would prefer not to declare {{{src/allmydata/web/static}}}
 And its subdirectories as being "packages" unless there is a good reason
 to do so, since I think it is semantically wrong according to Python
 packaging standards/customs/voodoo.

 Next weirdness: why is {{{src/allmydata/web/static/css}}} included in
 "packages" but {{{src/allmydata/web/static/img}}} isn't?

 Okay, my current guess is that the right thing to do is revert
 [2fa832b060ac8c4ceadb94d74d0ac5e0586e432c/trunk] and remove
 {{{allmydata.web.static}}} and {{{allmydata.web.static.css}}} from the
 list of packages on setup.py line 435. This should avoid warnings, should
 make it so that {{{import allmydata.web.static}}} gets an
 {{{ImportError}}}, and will force us to figure out how to include the
 static files in such a way that they would be open'able *even* from within
 a packed-into-a-single-file-app or other weird contexts.

 Question: what would it take to have warnings like this noticed and
 flagged by buildbot? We have some tests along those lines on buildbot, but
 I originally wrote them in-line into the buildmaster config, which was
 horrible, and I think Brian may have refactored them into files in
 [source:misc]... Yes, there they are in [source:misc/build_helpers]. Oh,
 actually, couldn't we just have the standard build command on buildbot
 treat warnings like these are errors? It is probably a setting in the
 buildmaster config.

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