On 15 Nov 2000, Mike Coleman wrote:
> Okay, but I'm thinking that not all .pycs should necessarily go in
> /usr/lib/pythonX.X (or whatever). I was thinking that generally useful python
> code should go in those directories, but that code that's really only useful
> as part of a particular applica
Mike Coleman <[EMAIL PROTECTED]> writes:
> Okay, but I'm thinking that not all .pycs should necessarily go in
> /usr/lib/pythonX.X (or whatever). I was thinking that generally useful python
> code should go in those directories, but that code that's really only useful
> as part of a particular app
Rob Tillotson <[EMAIL PROTECTED]> writes:
> Then we have no choice, all Python packages will have to depend on a
> specific version of Python and be installed under that version's
> library, no matter how the .pycs are supplied.
Okay, but I'm thinking that not all .pycs should necessarily go in
/
Moshe Zadka <[EMAIL PROTECTED]> writes:
> On 14 Nov 2000, Rob Tillotson wrote:
[...]
> > Any package that has a binary extension in it will necessarily have to
> > be compiled for a specific Python version.
>
> This isn't true. Python 1.5.2-compiled extensions will work just fine
> with Python
On 15 Nov 2000, Rob Tillotson wrote:
> How about the other way around? If the goal is to have 1.5.2 coexist
> with 2.0 on the same machine, this still presents a potential problem
> which will force packages to be dependent on one version or the
> other.
Correct: things built for 2.0 have a good
Moshe Zadka <[EMAIL PROTECTED]> writes:
> On 15 Nov 2000, Rob Tillotson wrote:
> > Moshe Zadka <[EMAIL PROTECTED]> writes:
> > > This isn't true. Python 1.5.2-compiled extensions will work just fine
> > > with Python 2.0.
> >
> > Hmm, they have changed the C API version several times in the past
>
On 15 Nov 2000, Rob Tillotson wrote:
> Moshe Zadka <[EMAIL PROTECTED]> writes:
> > This isn't true. Python 1.5.2-compiled extensions will work just fine
> > with Python 2.0.
>
> Hmm, they have changed the C API version several times in the past
> with minor releases, I guess it just didn't occur
Moshe Zadka <[EMAIL PROTECTED]> writes:
> This isn't true. Python 1.5.2-compiled extensions will work just fine
> with Python 2.0.
Hmm, they have changed the C API version several times in the past
with minor releases, I guess it just didn't occur to me that there
would be a major release without
On 14 Nov 2000, Rob Tillotson wrote:
> 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 wil
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 P
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 itse
>What might be a problem is where we put 3rd party modules.
In /usr/lib/pythonx.x/site-packages/
Bastian
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 int
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,
On Mon, 13 Nov 2000, [ISO-8859-1] Jérôme Marant wrote:
> So, .py scripts can be used with any Python releases without any problem.
> (.py files can then be compiled at postinst time).
This is the best way to hadnle it.
Something to still consider is whether we want to deal with Python 1.5.2
and P
> 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?
A good reason (mentioned in a previous thread) is that there are some
incompatibilities between byte
On Mon, 13 Nov 2000, Michael Sobolev wrote:
> On Thu, Nov 02, 2000 at 06:31:10PM +0100, Jérôme Marant wrote:
> > There is no need to include .pyc and .pyo in packages as python programs
> > can work without at first use. Moreover, this makes packages
> > bigger.
> BTW, what's the reason of m
On Thu, Nov 02, 2000 at 06:31:10PM +0100, JИrТme Marant wrote:
> There is no need to include .pyc and .pyo in packages as python programs
> can work without at first use. Moreover, this makes packages
> bigger.
BTW, what's the reason of making packages containing .py files? Is not it
better
Bastian Kleineidam <[EMAIL PROTECTED]> writes:
> BTW: is there yet a .deb package for the Distutils? If not, I will package
> it (when I am a Debian Developer, I am still in the queue).
It is already in woody and packaged by Matthias Klose.
It is named python-distutils.
--
Jérôme Marant <
Hi,
it seems there are some points to _not_ precompile Python files.
- packages get bigger (they get substantially bigger, more than twice
the size if they have lots of .py files)
- compatibility: I found the official wrapup
Third party extensions built for Python 1.5.x or 1.6
cannot be use
On Thu, 2 Nov 2000, Bastian Kleineidam wrote:
> >I recently created a debian file for my project (see http://subterfugue.org),
> >and discovered just now why including .pyc and .pyo files directly doesn't
> >work optimally.
> Where is the problem? Python bytecode should be platform
> independent!
[EMAIL PROTECTED] (Jérôme Marant) writes:
> Bastian Kleineidam <[EMAIL PROTECTED]> writes:
>
> > >I recently created a debian file for my project (see
> > >http://subterfugue.org),
> > >and discovered just now why including .pyc and .pyo files directly doesn't
> > >work optimally.
> > Where is th
Bastian Kleineidam <[EMAIL PROTECTED]> writes:
> >I recently created a debian file for my project (see http://subterfugue.org),
> >and discovered just now why including .pyc and .pyo files directly doesn't
> >work optimally.
> Where is the problem? Python bytecode should be platform
> independent!
Bastian Kleineidam <[EMAIL PROTECTED]> writes:
> >I recently created a debian file for my project (see http://subterfugue.org),
> >and discovered just now why including .pyc and .pyo files directly doesn't
> >work optimally.
> Where is the problem? Python bytecode should be platform
> independent!
>I recently created a debian file for my project (see http://subterfugue.org),
>and discovered just now why including .pyc and .pyo files directly doesn't
>work optimally.
Where is the problem? Python bytecode should be platform
independent! So it is safe to include .pyc and .pyo files. There is no
Hi,
I recently created a debian file for my project (see http://subterfugue.org),
and discovered just now why including .pyc and .pyo files directly doesn't
work optimally.
Looking at other packages which contain python code, it looks like there are
several slightly different variations on how th
26 matches
Mail list logo
