Forw: Packages in the Python source tree
From: Jeremy Hylton <[EMAIL PROTECTED]> To: Guido van Rossum <[EMAIL PROTECTED]> Cc: python-dev@python.org Subject: [Python-Dev] installing IDLE & other Tools Date: Mon, 13 Nov 2000 23:16:01 -0500 (EST) I just saw your note about whether IDLE was packaged with the Python RPMs. It isn't, nor is anything in the Tools directory. I did the simplest thing possible with the RPM and ran "make install". The RPM installs whatever is installed as a result of that. We've discussed installation of other tools once or twice, but I've never decided what exactly to do. The compiler package, for example, comes with a distutils setup.py script that will do the job. I think the best way to move forward is to write setup.py scripts for all the other tools that ought to be installed. I don't know how to package up idle cleanly, though. I need to decide what to install and where to install it. The Tools/idle directory is nominally a package, but it doesn't seem like that will help much for installing it. If we want to call the executable script idle.py, it will clash with the idle package name. Any advice here? It doesn't seem like there is any obvious way to "install" IDLE; it looks like it is intended to be run out of the source directory. If anyone else owns (or otherwise feels responsible for) a package in the Tools directory that ought to be included with the RPMs, please write a setup script for it. Jeremy -- Moshe Zadka <[EMAIL PROTECTED]> This is a signature anti-virus. Please stop the spread of signature viruses!
Re: question on packaging of python applications
On Mon, Nov 13, 2000 at 09:39:45PM +0200, Moshe Zadka wrote:
> > BTW, what's the reason of making packages containing .py files? Is not it
> > better to include only .pyo and .pyc files? And for those who really need
> > sources there those source packages?
>
> No! These are needed at run-time, togive better tracebacks.
Really? I am not sure. I can agree on your second stateme
> This is *crucial* for Python developers, since many time the traceback
> descends into the core modules, and it's important to be able to see what the
> proble is.
> IF you want, you can put the source files in the -dev packkage, though I
> still wouldn't recommend it.
Why? I do think that it's a good idea to separate .py{c,o} files from .py
ones. Look, I like mailman and want to make use of it, let's see:
Installed-Size: 1298
That's way too much for a server or something.
> Not putting the .pyc's is of course unacceptable too, unless the installation
> procedure creates them.
> THe reason is that since these are on /usr/lib, when an ordinary user imports
> them, no .pyc will be written since the user has no permissions there.
I believe that it's a good idea to depend on a specific version of python
anyway, and in this case, the package can easily ship .py{c,o} files only.
If the system administrator needs to what exactly happened, he can install -dev
package, or a source one.
To be honest, I want to see more arguments in favour of the current situation.
:)
--
Misha
Re: question on packaging of python applications
On Tue, 14 Nov 2000, Michael Sobolev wrote:
> Why? I do think that it's a good idea to separate .py{c,o} files from .py
> ones.
As was mentioned before, .py{c,o} is very specific to Python minor
version. The Python development team, while it is firmly commited to
source-compatability, has no intention of promising byte-code level
compatability. So, that would make .pyc packages depend on a specific
version, which is bad.
> Look, I like mailman and want to make use of it, let's see:
>
> Installed-Size: 1298
>
> That's way too much for a server or something.
Huh? I never heard of anyone else who had a problem with mailman's size.
> I believe that it's a good idea to depend on a specific version of python
> anyway
Why?
> If the system administrator needs to what exactly happened, he can install
> -dev
> package, or a source one.
A source one won't help him *at all* since Python won't be able to find
the source files unless they're in a specific place. And I've no love
for the whole -dev situation anyway...
--
Moshe Zadka <[EMAIL PROTECTED]> -- 95855124
http://advogato.org/person/moshez
Re: question on packaging of python applications
>What might be a problem is where we put 3rd party modules. In /usr/lib/pythonx.x/site-packages/ Bastian
Re: question on packaging of python applications
On Tue, 14 Nov 2000, Bastian Kleineidam wrote: > >What might be a problem is where we put 3rd party modules. > In /usr/lib/pythonx.x/site-packages/ Say module x Depends: on Python. Where do you install it? python1.5 or python2.0? Remember that you must encode this information in the package itself. -- Moshe Zadka <[EMAIL PROTECTED]> -- 95855124 http://advogato.org/person/moshez
Re: question on packaging of python applications
Moshe Zadka <[EMAIL PROTECTED]> writes: > Say module x Depends: on Python. Where do you install it? python1.5 or > python2.0? Remember that you must encode this information in the > package itself. Any package that has a binary extension in it will necessarily have to be compiled for a specific Python version. Quite a few of the most useful Python add-ons are in this category, so they would have to transition to Python 2.0 in the same manner that a normal application transitions to new versions of the libraries it depends on. For things which are truly independent of the Python version, there is /usr/lib/site-python. While python-base does not appear to create this directory, it is part of the default sys.path (in the current 1.5.2 packages) and there are at least two packages (reportbug and dpkg-python) which live there. --Rob -- Rob Tillotson N9MTB <[EMAIL PROTECTED]>
