Terry Hancock <[EMAIL PROTECTED]> wrote:
> Okay, I stand corrected.
>
> Three people including two I know are long-time developers
> have replied that .pyc/.pyo files are indeed architecture
> independent, and that changing this is unlikely:
Thanks for having asked the question on comp.lang.pytho
Okay, I stand corrected.
Three people including two I know are long-time developers
have replied that .pyc/.pyo files are indeed architecture
independent, and that changing this is unlikely:
From: Michael Hudson <[EMAIL PROTECTED]> Tuesday 18 November
2003 08:54:40 am
> Yes. .pycs are marshalle
On Monday 17 November 2003 03:35 pm, Florent Rougon wrote:
> Terry Hancock <[EMAIL PROTECTED]> wrote:
> > There was some discussion on comp.lang.python about
> > standardizing the bytecode awhile back, but the consensus
> > was that the standardized part of Python is *the source code*.
> > IMHO, t
Terry Hancock <[EMAIL PROTECTED]> wrote:
> There was some discussion on comp.lang.python about
> standardizing the bytecode awhile back, but the consensus
> was that the standardized part of Python is *the source code*.
> IMHO, they (/we) don't want to encourage obfuscated
> distributions of Pyth
Terry Hancock writes:
> On Monday 17 November 2003 09:22 am, Florent Rougon wrote:
> > Josselin Mouette <[EMAIL PROTECTED]> wrote:
> > > Le dim 16/11/2003 à 11:34, Matthias Klose a écrit :
> > >> There is no reason why /usr/share/ should be disallowed.
> > >
> > > That depends on whether .pyo files
On Monday 17 November 2003 09:22 am, Florent Rougon wrote:
> Josselin Mouette <[EMAIL PROTECTED]> wrote:
> > Le dim 16/11/2003 à 11:34, Matthias Klose a écrit :
> >> There is no reason why /usr/share/ should be disallowed.
> >
> > That depends on whether .pyo files really are architecture-independe
Hi,
Josselin Mouette <[EMAIL PROTECTED]> wrote:
> Le dim 16/11/2003 à 11:34, Matthias Klose a écrit :
>> There is no reason why /usr/share/ should be disallowed.
>
> That depends on whether .pyo files really are architecture-independent.
> At least the generated files are different on different a
Le dim 16/11/2003 à 11:34, Matthias Klose a écrit :
> There is no reason why /usr/share/ should be disallowed.
That depends on whether .pyo files really are architecture-independent.
At least the generated files are different on different architectures.
--
.''`. Josselin Mouette
Marco Paganini <[EMAIL PROTECTED]> wrote:
> So, it would be /usr/share after all, as the .py modules in question are
> not architecture dependent, but *are* private.
>
> Correct?
Yes, I think you can go for /usr/share/package.
--
Florent
Matthias Klose <[EMAIL PROTECTED]> wrote:
> Joss proposal is already incorporated into the proposed policy found
> in the python package.
>
> There is no reason why /usr/share/ should be disallowed. I
> changed the proposed policy to:
[private modules can now go to /usr/share/package/]
Good, tha
So, it would be /usr/share after all, as the .py modules in question are
not architecture dependent, but *are* private.
Correct?
Regards,
Paga
On Sun, Nov 16, 2003 at 11:34:59AM +0100, Matthias Klose wrote:
> Florent Rougon writes:
> > Yes, but obviously you haven't read the Python policy draft
Florent Rougon writes:
> Yes, but obviously you haven't read the Python policy draft
> (/usr/share/doc/python/python-policy.txt.gz) nor Josselin's proposal at
> http://people.debian.org/~joss/python/python-policy-draft.html/index.html.
> They are must reads for anyone packaging something that is
>
On Wed, Nov 12, 2003 at 10:51:44PM -0500, Marco Paganini wrote:
> >
> > Files used at runtime must not reside in /usr/share/doc, as this
> > directory can be deleted. They should rather be put in
> > /usr/share/package, and a symlink can be created in
> > /usr/share/doc/package/examples if this ma
Cory Dodt <[EMAIL PROTECTED]> wrote:
> I note that applications written in python, such as my aap package, go into
> /usr/lib/ per the policy (section 3.1.1), but linda does not support
> this. _all packages (most things written in Python) belong in /usr/share
> according to linda, but /usr/lib a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Nov 12, 2003 at 10:20:16PM +0100, Josselin Mouette wrote:
> > Another question: My application has some "skeleton" files that are copied
> > to the user's home directory by an installation program. Robert Millan (my
> > Debian guru, in the Cc:
Le mer 12/11/2003 à 20:32, Marco Paganini a écrit :
> - I should bytecompile the modules at installation time. This matches my
> original expectations. However, the Python Policy is not clear about
> where I should put the byte-compiled files. Is /usr/lib/package an
> acceptable place? It wou
On Wed, Nov 12, 2003 at 02:32:30PM -0500, Marco Paganini wrote:
> Another question: My application has some "skeleton" files that are copied
> to the user's home directory by an installation program. Robert Millan (my
> Debian guru, in the Cc:) has recommended /usr/share/doc/package/something,
> bu
On Wed, Nov 12, 2003 at 02:32:30PM -0500, Marco Paganini wrote:
> - According to Python's Policy, section 3.1.1, private modules should be
> installed in /usr/lib/site-python/module,
> /usr/lib/pythonX.Y/site-packages/module
> or /usr/lib/package. In my case, it makes more sense to install th
Hi Florent,
On Wed, Nov 12, 2003 at 03:50:35PM +0100, Florent Rougon wrote:
> [Ugh, sorry for the double message, Marco]
Worry not! :)
> Yes, but obviously you haven't read the Python policy draft
> (/usr/share/doc/python/python-policy.txt.gz) nor Josselin's proposal at
> http://people.debian.or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I note that applications written in python, such as my aap package, go into
/usr/lib/ per the policy (section 3.1.1), but linda does not support
this. _all packages (most things written in Python) belong in /usr/share
according to linda, but /usr/lib a
[Ugh, sorry for the double message, Marco]
Marco Paganini <[EMAIL PROTECTED]> wrote:
> Hi All,
Hi,
> I need to package a Python application that depends on multiple modules.
> I've been wondering about the correct location for the modules (both .py and
> .pyc files) in Debian. FHS states that a
21 matches
Mail list logo
