Re: Help with my Debian package for Orange
On Jul 01, 2011, at 01:00 AM, Mitar wrote: >I will not yet use "dh" as it looks too magical for me for now. I >would like to understand what is happening. And first have a working >package. Then I can play with cleaning it up. Or would it be easier to >just let dh do everything? I doubt it can be magical enough. Personally, I find dh preferable, even with the magical aspects. You can always set DH_VERBOSE=1 to get decent output about exactly what it's doing. I think dh and dh_python2 make a great way to very easily package up most Python libraries. I have some recommendations to add for extension modules coming soon to the dh_python2 transition wiki page. -Barry signature.asc Description: PGP signature
Re: Help with my Debian package for Orange
On 06/29/2011 06:58 PM, Mitar wrote: > I have made a Debian package for Orange: > > http://orange.biolab.si/ > > The idea is that we have a daily snapshot packaged as Debian package. > > You can get it here (also source package): > > http://orange.biolab.si/debian/ FYI, a separate packaging was already attempted sometime in the past. You can find the SVN repository for the packaging here: http://anonscm.debian.org/viewvc/collab-maint/deb-maint/orange-data-mining/ I don't know how current this is, but there might be some helpful stuff in there. Either way, if you indeed will start to provide packaging upstream, then the above repo should probably be removed to avoide confusion. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e0dcb3d.1000...@kvr.at
HELP
HELP -- mauro mauro [at] majaglug [dot] net -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e0dc926.3090...@majaglug.net
Re: Help with my Debian package for Orange
Hi! On Fri, Jul 1, 2011 at 3:27 PM, Christian Kastner wrote: > I don't know how current this is, but there might be some helpful stuff > in there. Either way, if you indeed will start to provide packaging > upstream, then the above repo should probably be removed to avoide > confusion. Yes. This is quite old. ;-) For at least some time I will be able to provide packaging. I think once we get rules script in order, then there will not be much work to do, just updating dependencies and so on. I still have those two problems: how to compile for multiple architectures and how to configure ld path (or use rpath?). Mitar -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktikm5-j-2rvgjgz+uduca05_-jo...@mail.gmail.com
Re: Help with my Debian package for Orange
On 07/01/2011 05:21 AM, Barry Warsaw wrote: > On Jul 01, 2011, at 01:00 AM, Mitar wrote: > >> I will not yet use "dh" as it looks too magical for me for now. I >> would like to understand what is happening. And first have a working >> package. Then I can play with cleaning it up. Or would it be easier to >> just let dh do everything? I doubt it can be magical enough. > > Personally, I find dh preferable, even with the magical aspects. You can > always set DH_VERBOSE=1 to get decent output about exactly what it's doing. I > think dh and dh_python2 make a great way to very easily package up most Python > libraries. I have some recommendations to add for extnsion modules coming > soon to the dh_python2 transition wiki page. It's definitely preferable for an experienced packager, it can be confusing as hell though to the commencing packager because in order to understand dh syntax, you must first understand what debian/rules does, ie the actual process of building a package from source. Additionally, stuff like "dh_installmanpages" (regular or dh syntax) is completely obvious to us, but the commencing packager * must first understand what that command tries to accomplish * must understand how it accomplishes it * must understand when it accomplishes it (at what stage) * must realize that even though it is a quasi-standard, it it "just" a helper, and there are other ways to accomplish the same thing * etc At least, that's the way I saw it when I started packaging about a year ago, and getting familiar was a time-consuming process. I'd recommend getting started with either the New Maintainainer's Guide[0] or the Packaging Tutorial Yarik posted, and probably with a simpler package. Once the basics are solid, stuff like dh (and other helpers) become natural. Christian [0] http://www.debian.org/doc/manuals/maint-guide/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e0dca4c.1000...@kvr.at
Re: Current state of packaging Python software for Debian
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 signature.asc Description: PGP signature
Re: Help with my Debian package for Orange
On Jul 01, 2011, at 09:23 AM, Christian Kastner wrote: >It's definitely preferable for an experienced packager, it can be >confusing as hell though to the commencing packager because in order to >understand dh syntax, you must first understand what debian/rules does, >ie the actual process of building a package from source. And once you understand packaging, it becomes pretty boring pretty quickly. ;) -Barry signature.asc Description: PGP signature
Re: Current state of packaging Python software for Debian
On Jun 15, 2011, at 05:07 PM, Éric Araujo wrote: >Yes, last summer’s GSoC added a test command, which defaults to >unittest(2) test discovery and can be configured to use any test runner >on any test suite. It runs tests against the modules in the build >directory, to be able to work with code converted at build time with >2to3 (and soon, to be able to access the PEP 376 dist-info files). >Barry, I’m waiting for reports about the problems you ran into :) IIRC, they were problems with doctests not getting properly converted, but I forget the details at the moment. I'll try Python 3.3/packaging again soon and definitely file bugs for anything I find. Can I use the Python tracker for those? >Regarding Sphinx, I don’t think it would be appropriate to add a command >for it in the stdlib. We already have upload_docs, which can upload any >set of HTML files. Well, almost. I think there are some problems with that in Python 2, such as if the Sphinx docs aren't laid out in the particular way expected by `upload_docs`. E.g. say you don't have an index.html file but you do have a README.html. >However, it’s much easier to add custom command in packaging¹, so Sphinx’ >distutils-based build² command can be used with pysetup. That probably makes sense given that Sphinx is a separate project, but whatever we can do to make it easy to use the de-facto standard, the better. For example, `python setup.py build_sphinx` is a pretty lousy command name, but that's Georg's problem. ;) OTOH, if packaging supports command extensions, then `pysetup build` should Just Work to build the docs too, when Sphinx is installed and docs are written in reST. >In some sub-communities, py.test or nosetests are the standard, not >setup.py test. Yes, but if I understand where Michael is taking unittest2, those can just be refactored to be plugins instead of separate standards. Then `python setup.py test` can be the preferred and documented standards, while allowing those other command lines to also exist. Cheers, -Barry signature.asc Description: PGP signature
Re: Current state of packaging Python software for Debian
On Jun 15, 2011, at 02:39 AM, Zygmunt Krynicki wrote: >I agree in the value but I don't want to assume that it is a default practice >or requirement. I package/hack on the webapp (django) side of tests and after >being spoiled with the goodness of python-testtools and python-testscenarios >I ventured to create equivalents (compatible wrappers really) for >django. This means that my packages build depend on 5 additional packages >just for testing. I really hope we could take an 80/20 approach here. IOW, do by default that which *most* packages will benefit from, which IMHO is installing the tests by default. Those packages which have additional dependencies, huge test data, or complicated tests can always add overrides to separate things into a -tests package. Or, make the common things trivial and the difficult things possible. :) -Barry signature.asc Description: PGP signature
