Re: Documenting Python Debuntuisms
Barry First, when Python searches for a module to import, only Barry sys.path is consulted (modulo other import hooks). It doesn't Barry really treat $PYTHONPATH or the cwd any differently. It does Barry initialize sys.path from $PYTHONPATH and it does (sometimes) Barry include a special marker (the empty string) first on sys.path to Barry indicate the cwd, but once Python's machinery gets going Barry $PYTHONPATH is ignored. Thanks for pointing this out. I made the appropriate changes. [skipping a lot of lines ...] Barry This means that if you install Python from-source, as many Barry Python developers do through the default cmmi build, and system Barry administrators do achieve Python builds isolated from critical Barry system resources, you could break your system Python by Barry installing incompatible packages into what you thought was an Barry isolated environment. You mean because the source install of Python installs into /usr/local/lib/python3.1/site-packages in addition to /usr/local? It still does if I recall correctly. Barry Because it was unlikely upstream Python was going to change Barry (e.g. To install from source by default into /opt) or that Barry Debian Python policy was going to change, Doko came up with a Barry clever compromise of changing the system Python's /usr/local Barry claim to be dist-packages instead (mirrored to /usr/lib space Barry for convenience and consistency). This seemed like a perfectly Barry workable solution, which I still agree with, despite the mild Barry surprise factor for seasoned non-Debian-versed Python Barry developers. -- 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/87iq4g3a0s@wks.sunoano.org
Re: unused substitution,variable ${python:Versions}
OoO Lors de la soirée naissante du mercredi 14 juillet 2010, vers 17:17, Bernd Zeimetz be...@bzed.de disait : I'm working on package that uses CDBS That's not a very good choice. Why? Because cdbs is an unmaintainable beast of Makefiles. I'm not sure who is willing to keep the Python parts in there working. Since we have dh, which is a sane piece of code with a sane upstream, most new packages use dh. And I know several people who are willing to update dh to work with new Python versions/packaging changes if necessary. cdbs is a simple piece of software to maintain a Python package. Until recently, it was the only option to get a debian/rules as short as this: #!/usr/bin/make -f DEB_PYTHON_SYSTEM = pysupport include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/python-distutils.mk I still prefer cdbs to dh because it is easier to configure by just setting variables. I know that there is some drawback (see for example #386970 that is still not solved) but for simple packages, it just does its job. I think that since it is major piece of Debian (still an official way to build a package), we should ensure that it will work with the new policy. I will try to take care of this (and I will look at other python related bugs currently in BTS). -- I AM NOT A DENTIST I AM NOT A DENTIST I AM NOT A DENTIST -+- Bart Simpson on chalkboard in episode 7F24 pgpFLPsNOIw6s.pgp Description: PGP signature
Re: [Half-OT] Plone and: Re: python 2.6 deb for lenny ?
On 6/24/10 12:58 AM, Fabio Tranchitella wrote: IMHO, the real mess is Plone itself: it can be a great platform, but it is a nightmare to deploy and maintain. I couldn't agree more. I sent a message to the pkg-zope-developers mailing list yesterday about packaging zope2.12 and plone4.[0] This so far has resulting in the suggestion to use z3c.recipe.debian, which is a buildout recipe for creating a debian package out of a buildout. And as I explained in a followup to that email.[1] A summary of that message: Plone is not a fixed application and therefore packaging a buildout will likely cause me pain in the long run. I won't use buildout in production *period*. I experimented with using pip to help in building a packaged version of Plone. That failed because of zope.configuration. You can see my thread for further details.[2] So I'm fairly stuck at this point, but I'm not giving up. I'm going to package plone no matter how many times it kicks me in the head (or at least until brain damage ensues). Any one else feel like joining me? :) [0] http://lists.alioth.debian.org/pipermail/pkg-zope-developers/2010-July/006426.html [1] http://lists.alioth.debian.org/pipermail/pkg-zope-developers/2010-July/006440.html [2] http://sourceforge.net/mailarchive/message.php?msg_name=4C3C5AA0.2090806%40psu.edu -Michael Mulich (pumazi) -- 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/4c3f747a.4090...@psu.edu
karaage
Hello All, As part of my paid Job I am working on Karrage, and open source Django based application application for management of users and resources on shared cluster systems. http://code.vpac.org/trac/karaage As this is an open source GPL program (yes, management have already agreed to this), long term I would like to see this included in Debian. Short term however, there are a number of technical issues that need resolving. For example, dependencies on external libraries that are not yet in Debian. On issue that has been nagging us - what is the best way to handle python based config files? e.g. the settings.py file that is standard for Django applications? At present our (planned but not implemented) approach is to have our python dist-utils script create a directory karaage/conf under the python path, and then karaage can import then using import karaage.conf.settings for example. Use of dist-utils and cdbs makes the debian/rules file very simple. However, from the point of view of the package, it would be better if we could put the config files under /etc/karaage. Just wondering if this situation has been encountered before? If so, would rather use an existing solution rather then invent my own. Ideally any solution should be similar to what you would get by installing directly from source and RPMs too. Also: Is there any Debian specific concerns I should be aware of when packaging Django applications? Please CC me, I am not subscribed (not yet anyway). Thanks. -- Brian May br...@microcomaustralia.com.au -- 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/aanlktinfswwqq0vxpeskclnuitkrfzkuiucp_eeur...@mail.gmail.com
Re: karaage
On Fri, Jul 16, 2010 at 8:03 AM, Brian May br...@microcomaustralia.com.au wrote: On issue that has been nagging us - what is the best way to handle python based config files? e.g. the settings.py file that is standard for Django applications? This sounds like more of a question for the webapps list. My standard answer for webapps is that the package should not assume which URL it is installed at, not assume there will be only one instance of it and not assume where the sysadmin would like to keep uploaded user data. So you probably need dbconfig-common, wwwconfig-common and some debconf prompts to ask the sysadmin if the want to create an instance at install time and then ask appropriate questions about how many instances, which URLs they should be at and where on the filesystem or which database hosts to use. For stuff like automated database upgrades you can use a configuration file in /etc that lists all the instances to upgrade. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/aanlktingfk9zy1w4w_evoivmceaginxyumofiqdsi...@mail.gmail.com
Re: unused substitution,variable ${python:Versions}
On Wed, 14 Jul 2010, Matteo Vescovi wrote:
Could you please point me to an existing python package that uses dh
that I can use as an example starting point?
An example package that handles a pure python modules and an extension
module would be great.
For properly bundled pure Python one you merely need
/usr/share/doc/debhelper/examples/rules.tiny
as your debian/rules ;)
cdbs would work as fine for you there too (it used to be my favorite ;))
But if you want a good example for a Python module primarily based
on an extension (i.e. there is not much of Python arch-indep code),
Christian Kastner pointed me today to Jakub's good work on python-djvu
-- there you get an example which provides proper python-*-dbg package,
does unittesting for all versions (including -dbg) during build and
builds the documentation, with not too much of debian/rules since it
relies on dh's builtin functionality primarily.
If you do have a mix of relatively large amount of Python code and
arch extensions, you might like to look into packages which provide
arch-indep python-bla, and then python-bla-lib{,-dbg} for extensions.
E.g. you could look into mine python-nipy although it isn't using the
latest -dbg logic of dh (TODO for me ;)), so not yet the nicest example.
Cheers,
--
.-.
=-- /v\ =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User^^-^^[17]
signature.asc
Description: Digital signature
