Apologies for the delayed response. On Jun 15, 2011, at 01:03 AM, Zygmunt Krynicki wrote: >W dniu 15.06.2011 00:04, Barry Warsaw pisze: >> On Jun 14, 2011, at 05:53 PM, Zygmunt Krynicki wrote: >> >>> Can please we have standardized hooks to build sphinx documentation and run >>> setup.py test tests? >> >> I'd like to see the packaging folks address this. Eric is subscribed to >> this list and can probably speak to packaging's take on it, but my >> preferences would be that >> >> $ pysetup test > >I have no practical knowledge of python3 (are we there yet?) so I cannot >comment but... Depends on where "there" is :). Yes, you can write real things in Python 3, and you can fairly easily write code that runs in both Python 3 and 2. The catch of course is whether your entire dependency stack is available for Python 3. We're only going to get better at that over time. > In Python< 3.3, using >> setuptools/distribute/distutils2, this should be the standard interface: >> >> $ python setup.py test > >I would also like this to become the de-facto standard. Can we somehow make >it happen? (debian policy, python something?)3.3). I think there are a couple of steps. First, make sure all your own code supports this standard, and encourage the authors of any code you package or run across to do the same. The other part is to strongly encourage use of this interface by supporting tools, in Python, Debian, Ubuntu and elsewhere. For example, I'd love to see a "quality measure" on PyPI that simply ran the tests using this interface and giving a GOOD/BAD/DUNNO state right on the main page. This way, we don't have to wield a heavy stick to get people to adopt the convention because developers will want to turn the red or yellow status to green. We could also hook the Debian build system to run `python setup.py test` on build by default and complain when that's missing, or fail when the tests don't pass. >Below I cut most of the discussion where we agree on sphinx documentation and >python. > >> In a setup.py world: >> >> $ python setup.py build_sphinx > >[cut] > >This is all fine and pretty (thanks to python). On the debian side I always >have to copy-paste the same-looking code over and over again (symlink jquery, >don't compress .js and .css, build-depend on sphinx and recommend jquery on >-doc package. Always the same boring and useless text in -doc-base files. All >begs for automation. Yep! >> Georg (the upstream Sphinx maintainer) makes a good point, which is that he >> really can't be expected to test Sphinx with any version of jquery than the >> one he ships. Operating systems (Debian/Ubuntu) are the integrators, and >> as Jakub points out in that issue, if Debian deviates from upstream by >> replacing Sphinx's version of jquery, it's incumbent on Debian to ensure it >> works properly. > >I agree, still, in the end there are only two possible choices: > >1) We stop replacing the bundled jquery and recommend this as best practice. > >2) We keep stripping jquery and replacing it with a symlink to libjs-jquery >but we make the process less cumbersome and manual. I think #2 will always be problematic. The advantage of the current approach is that it's easier to manage for security purposes. The disadvantage is that someone needs to ensure the same version of the library works across every package that links to it. Seems to me that could be an intractable problem. -Barry
Attachment:
signature.asc
Description: PGP signature