Re: when and why did python(-minimal) become essential?
Matt Zimmerman [EMAIL PROTECTED] writes: One example is .config maintainer scripts, some of which are quite complex and worth writing in a higher-level language than shell. This is surely true; Steve Langasek asked if this was a real issue in Ubuntu or merely a potential issue. Granted if it is a real issue, then why not use perl? Yes, I hate perl too, but really, the argument hey, people like Python too implies that we should have a scheme interpreter, a perl, a python, emacs lisp, and well, everything anyone might want. Or, we say we aren't going to support *every* high-level language and stick to one. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Matt Zimmerman [EMAIL PROTECTED] writes: On Fri, Jan 20, 2006 at 09:40:55AM -0800, Steve Langasek wrote: I asked this question earlier, and no one answered. Are there .config scripts being written in python today in Ubuntu? (Hmm, where are the python bindings for debconf, and what ensures that they're installed?) No, not yet. The promotion to Essential needed to happen prior to writing any such scripts. Are there .config scripts written in other languages? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python packaging infrastructure
Steve Langasek writes: On Fri, Jan 20, 2006 at 10:47:19AM +0100, Matthias Klose wrote: Steve Langasek writes: On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote: the design decision of putting the binary-all python packages in a separate directory into /var/lib/python2.x/site-packages has some problems when supporting packages with extensions (a proposal beeing made on #irc was to keep the extensions in the standard path). If they are in different directories, then foomod.py already doesn't enjoy a privileged location in the current path; so whether they are symlink-farmed or not, there must already be handling in place to locate foomod.py, so it doesn't much matter which particular directory it's located in. Perhaps you are arguing that a package should be able to ship /usr/lib/python2.3/site-packages/foo/fooext.so and /usr/lib/python/site-packages/foo/foomod.py, and have the infrastructure make foomod.py (or foomod.pyc?) available in /usr/lib/python2.3/site-packages/foo. I'm not sure why this would be advantageous? So how does python-support handle packages, where the extension module is split out in it's own binary package? If they're split out in separate binary packages, then surely the extension package doesn't require any special handling, and the module package can be managed as before? yes, another bunch of packages which then cannot be handled by the packaging infrastructure. Uh, no, I meant can be managed as before [by python-support]. (since obviously it's not sensible to split /usr/lib/python2.3/site-packages/foo between two separate packages...) obviously? - In the past packagers were encouraged to split packages this way to save disk space (at least on the ftp mirrors), if the size of the arch independent part exceeds the arch dependent part significantly. - packages are split this way, if the package does depend on other libraries or packages, which are not always needed (i.e. have a dependency on X in a separate package, have a separate package for each database adaptor, built from the same package source). - packages are distributed upstream this way, so you have different sources sounds rather sensible to split these. Ah. So this happens in practice? These do all seem to be reasonable; apparently my obvious answer was wrong. :) Coming back to: Perhaps you are arguing that a package should be able to ship /usr/lib/python2.3/site-packages/foo/fooext.so and /usr/lib/python/site-packages/foo/foomod.py, and have the infrastructure make foomod.py (or foomod.pyc?) available in /usr/lib/python2.3/site-packages/foo. I'm not sure why this would be advantageous? I.e. in version 1, a package is implemented as a pure python module, the package maintainer uses the new packaging infrastructure, version 2 implements some functionality in an extension module to speedup things. Why does a package maintainer have to change the packaging infrastructure? Er... because the nature of the package has changed? There are going to be changes required here anyway; adding a .so to the package means it can no longer be arch: all, can no longer be invariant wrt multiple python versions, has to build the module once for each flavor of python supported, etc. I believe we should provide the best possible packaging tools to simplify this for maintainers, but I think that expecting a maintainer not to have to do any work to convert from a pure-python package to a package with an extension is unrealistic. no, but it breaks unrelated (maybe binary all) packages as outlined in the second scenario below. Btw, perl has had split arch:any/arch:all paths for modules for years, and I haven't heard anyone complaining about it; I'm really not sure why python should be different. - Perl seems to have a more stable ABI for it's extensions - Perl doesn't have version dependent byte code files, which are not compatible across versions. Make it worse, if a pure python module offering some kind of plugin structure uses the infrastructure, another package (maybe even maintained by somebody else) chooses to implement the plugin as an extension enforces the other maintainer to drop using the packaging infrastructure. This is because the plugin search path will be relative to the directory the python module is installed in? Can you give me some example python code that would fail in this scenario? why another one? there's one which shows this behaviour. it is enough to show that it doesn't work. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Fri, Jan 20, 2006 at 11:14:19AM -0800, Matt Zimmerman wrote: If you won't acknowledge that, then know that upstream also object to the name python-base for something which has a stripped-down standard library. Both pythol-minimal and python-base sound to something an end user would expect to contain a minimal, but working, python environment from end user POV. I would go for a name that clearly discourages an end user from thinking that (python-minlib, python-installerlib ... other better names). Not to mention that description should heavily discourage end users from thinking that way. Suggestion from Thomas Hood seems good to me, that means you are not installing python, just some elements you need, and you are not claiming to have installed python since 'python' is not available as that in the search path. -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-sqlobject v0.7 package?
Ramon Bastiaans wrote: I was wondering on the status of a version 0.7 package for python-sqlobject. It's current package is still at version 0.6, while version 0.7 has been released in October 2005. I'll confess that I'm partly to blame for the delay. v0.7 needs formencode and Fabio contacted me about my ITP for formencode. I've been dragging my feeting waiting for the whole .egg/.deb debate to be resolved. I've removed the .egg stuff from the latest release, I just need to get the directory names debian compliant. I hope to work on it 01/22 or 01/23. -- Bob Tanner [EMAIL PROTECTED] | Phone : (952)943-8700 http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Martin Michlmayr wrote: I definitely agree we should listen to the Python community, Well, my *personal* view is this: I agree that it is highly desirable that the python package is the entire thing, with all batteries included. I'm uncertain what to think about offering systems that only have a minimal python, which would have python not installed, yet /usr/bin/python present. On the one hand, I think it is fair to require people to install the python package if they want Python. OTOH, it is likely also confusing to tell people that they need to install python even though /usr/bin/python is already present. I cannot guess how many support requests we would get from people which fail to install the python package. We surely get a lot of requests from people asking why some Python program fails, just because some Linux distributions manage to install an incomplete library even though the user requested the python package of that distribution. In that category, the most frequent issue is that people cannot run distutils applications, either because the entire distutils library is missing, or because the header files are missing. The next most frequent issue is that people complain they cannot run IDLE (because Tkinter was not installed). Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Sat, 2006-01-21 at 01:48 -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: One example is .config maintainer scripts, some of which are quite complex and worth writing in a higher-level language than shell. This is surely true; Steve Langasek asked if this was a real issue in Ubuntu or merely a potential issue. Granted if it is a real issue, then why not use perl? Yes, I hate perl too, but really, the argument hey, people like Python too implies that we should have a scheme interpreter, a perl, a python, emacs lisp, and well, everything anyone might want. Or, we say we aren't going to support *every* high-level language and stick to one. There's nothing that prevents us saying we aren't going to support every high-level language and stick to more than one (we already stick to two -- sh and Perl). It just means I'd like to write scripts in X alone isn't a good enough reason. Python is the official language of Ubuntu. If we want to merge work they're doing (Anthony Towns mentioned their work on boot speed, for example) it's a good idea to structure our Python like theirs is. This seems to be a good reason to consider python-minimal and some form of Python in Essential. The real issue here is that the original upload didn't do that; it went through the motions without actually changing our Python packaging or upgrading the version, so we just got all of Python as Essential. No one wanted that. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: when and why did python(-minimal) become essential?
On Sat, Jan 21, 2006 at 01:48:11AM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: One example is .config maintainer scripts, some of which are quite complex and worth writing in a higher-level language than shell. This is surely true; Steve Langasek asked if this was a real issue in Ubuntu or merely a potential issue. Granted if it is a real issue, then why not use perl? Yes, I hate perl too, but really, the argument hey, people like Python too implies that we should have a scheme interpreter, a perl, a python, emacs lisp, and well, everything anyone might want. Ubuntu developers would like to be able to use Python. So far there has been no demand whatsoever for LISP derivatives in this context. Or, we say we aren't going to support *every* high-level language and stick to one. We aren't going to support every high-level language, but we do support more than one in Ubuntu. This, of course, has no particular bearing on whether Debian follows suit. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Joe Wreschnig [EMAIL PROTECTED] writes: There's nothing that prevents us saying we aren't going to support every high-level language and stick to more than one (we already stick to two -- sh and Perl). It just means I'd like to write scripts in X alone isn't a good enough reason. Yes, this is true. Python is the official language of Ubuntu. If we want to merge work they're doing (Anthony Towns mentioned their work on boot speed, for example) it's a good idea to structure our Python like theirs is. This seems to be a good reason to consider python-minimal and some form of Python in Essential. This does not scale. If each Debian derivative chooses a different official language, and we put each of them in Essential, then we end up with every language in Essential. Debian already *has* an official language for this purpose: Perl. If Ubuntu wants to replace that with Python, it's up to them, but it seems like a lot of work. What I hear is *not* that Python is the official language instead of Perl, but that it is the official language *in addition to* Perl. So now, why? Remember, I'd like to write scripts in X is not a good enough reason, so what is the reason for having two official languages? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Matt Zimmerman [EMAIL PROTECTED] writes: Granted if it is a real issue, then why not use perl? Yes, I hate perl too, but really, the argument hey, people like Python too implies that we should have a scheme interpreter, a perl, a python, emacs lisp, and well, everything anyone might want. Ubuntu developers would like to be able to use Python. So far there has been no demand whatsoever for LISP derivatives in this context. Ok; Joe Wreschnig just said that I would like to write scripts in X is certainly not a good enough reason to add X to Essential. It sounds as if you are in disagreement with him; have I understood correctly.? Or, we say we aren't going to support *every* high-level language and stick to one. We aren't going to support every high-level language, but we do support more than one in Ubuntu. The question is, why? Is it just we want to use Python too? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Sat, Jan 21, 2006 at 02:21:34PM -0600, Joe Wreschnig [EMAIL PROTECTED] wrote: Python is the official language of Ubuntu. If we want to merge work they're doing (Anthony Towns mentioned their work on boot speed, for example) it's a good idea to structure our Python like theirs is. This (...) Boot speed and python does not really sound a match... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Matt Zimmerman [EMAIL PROTECTED] writes: On Sat, Jan 21, 2006 at 01:04:25PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: Granted if it is a real issue, then why not use perl? Yes, I hate perl too, but really, the argument hey, people like Python too implies that we should have a scheme interpreter, a perl, a python, emacs lisp, and well, everything anyone might want. Ubuntu developers would like to be able to use Python. So far there has been no demand whatsoever for LISP derivatives in this context. Ok; Joe Wreschnig just said that I would like to write scripts in X is certainly not a good enough reason to add X to Essential. It sounds as if you are in disagreement with him; have I understood correctly.? I have said repeatedly that I am not expressing an opinion about what Debian does with regard to python-minimal. The only reason I am participating in this thread is to answer questions about what we did in Ubuntu and why, and I think I've done that thoroughly now. No, really, I'm trying to understand Ubuntu's reasoning here, and not just the actions undertaken. I understand the actions, but I don't understand exactly what the reasons are, and it would help me. The reasons you gave are different than what Joe Wreschnig said; he spoke of Python being Ubuntu's official language and whatnot, though what he meant is not that Ubuntu has replaced Perl with Python, but that Python has been added in. I can understand We like Python more than Perl, so we replaced Perl with Python, though that would be a lot of work and it isn't what the actual reasoning was anyway. It seems to be simply that one more official language has been added. Personally, I can't stand either Python or Perl. This gives me a different perspective. It's not about liking one or the other, but about the need for Debian to congeal as a whole on a single choice, lest we need to have every choice. So I'm wondering, what are the restraints upon the same things at Ubuntu? Is it just a flat we like Python and Perl and nothing else or is it we add any language that there is demand for among Ubuntu people or what? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Don't reply to me directly. I should not have to tell you this. On Sat, 2006-01-21 at 13:03 -0800, Thomas Bushnell BSG wrote: Python is the official language of Ubuntu. If we want to merge work they're doing (Anthony Towns mentioned their work on boot speed, for example) it's a good idea to structure our Python like theirs is. This seems to be a good reason to consider python-minimal and some form of Python in Essential. This does not scale. If each Debian derivative chooses a different official language, and we put each of them in Essential, then we end up with every language in Essential. We can burn those bridges when we come to them. Right now there's only one such distribution, with one such language, which has already done all the work to strip it down to a small size. Unless you expect some derived Debian distribution to use Scheme some day, this is sophistry. If you really do expect that, it's insanity. What I hear is *not* that Python is the official language instead of Perl, but that it is the official language *in addition to* Perl. So now, why? Remember, I'd like to write scripts in X is not a good enough reason, so what is the reason for having two official languages? I don't manage Ubuntu policy, nor do I want to. I am a Debian developer interested in Debian. The argument for Debian is not I'd like to write scripts in X but There is this large body of people writing scripts in X, and it'd be nice if we could work with them. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: when and why did python(-minimal) become essential?
On Sat, Jan 21, 2006 at 01:04:25PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: Granted if it is a real issue, then why not use perl? Yes, I hate perl too, but really, the argument hey, people like Python too implies that we should have a scheme interpreter, a perl, a python, emacs lisp, and well, everything anyone might want. Ubuntu developers would like to be able to use Python. So far there has been no demand whatsoever for LISP derivatives in this context. Ok; Joe Wreschnig just said that I would like to write scripts in X is certainly not a good enough reason to add X to Essential. It sounds as if you are in disagreement with him; have I understood correctly.? I have said repeatedly that I am not expressing an opinion about what Debian does with regard to python-minimal. The only reason I am participating in this thread is to answer questions about what we did in Ubuntu and why, and I think I've done that thoroughly now. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Joe Wreschnig [EMAIL PROTECTED] writes: We can burn those bridges when we come to them. Right now there's only one such distribution, with one such language, which has already done all the work to strip it down to a small size. Scalability problems do not happen because someone failed to stop the tenth extra case. They happen because nobody stopped the second. Unless you expect some derived Debian distribution to use Scheme some day, this is sophistry. If you really do expect that, it's insanity. I once thought that it was insanity to expect Python to be in broad use. I was wrong. I don't manage Ubuntu policy, nor do I want to. I am a Debian developer interested in Debian. The argument for Debian is not I'd like to write scripts in X but There is this large body of people writing scripts in X, and it'd be nice if we could work with them. Yes, I understand. I'm trying to understand--from a Debian perspective--whether there are any limits, or it really just is lots of people are writing scripts in X? And, how many scripts are we talking about anyway? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
what package name to decide
Hi, I want to Debian package the little shout-python software: http://icecast.org/download.php (in the midle of the page) The upstream tarball is: http://downloads.us.xiph.org/releases/libshout/shout-python-0.2.tar.gz What name should I give to it? - libhsout-python ? - python-shout ? - shout-python ? Thank you. -- A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source GPL). Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better. http://www.cps-project.org for downloads documentation. Free hosting of CPS groupware: http://www.objectis.org. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-icecast-devel] what package name to decide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 22 Jan 2006 00:18:57 +0100 Rakotomandimby Mihamina [EMAIL PROTECTED] wrote: I want to Debian package the little shout-python software: http://icecast.org/download.php (in the midle of the page) The upstream tarball is: http://downloads.us.xiph.org/releases/libshout/shout-python-0.2.tar.gz What name should I give to it? - libhsout-python ? - python-shout ? - shout-python ? Even though the software is promoted as shout-python, the actual Python module seems to be named just shout, so I believe the correct name is python-shout (and python2.3-shout, python2.4-shout and so on). But why do you ask this mailinglist? You are most welcome to join the group and have the package group-maintained, if that's what you want. I just must warn you if you are in the process of becoming an official Debian developer that your work as part of a group may require some convincing to be included in your application. I will back you up if interested. You could also consider having it group-maintained by the Alioth group pkg-xiph... Regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD0u8vn7DbMsAkQLgRAvYkAKCizciCj/rrLfhV7vECDld1JDjtqgCfXfJh nzjkGBlL7f6i4rX/HRmye9A= =sDlx -END PGP SIGNATURE-
