Re: Bug#791635 python-policy: Please require namespacing source python module packages

Hi Scott (2023.01.29_01:34:54_+) > It'd be much simpler just to drop DPT or myself from uploaders and ignore > this, so that's probably the path I would take. The Debian Python Policy is independent of DPT. So, if adopted, that wouldn't help much... :) > Regardless, I do

Re: Bug#791635 python-policy: Please require namespacing source python module packages

package being removed from >sid, reopening and reassigning where python-policy seems to be located >now. > >On Tue, 2022-12-27 at 23:29:30 +, Debian Bug Tracking System wrote: >> Date: Tue, 7 Jul 2015 03:11:06 +0200 >> From: Guillem Jover >> To: sub...@bugs.d

Re: Bug#791635 python-policy: Please require namespacing source python module packages

Control: reopen -1 Control: reassign -1 python3 [ Sorry, resending, as the bug was archived so it ignored all the control commands. ] This got closed due to the python-defaults package being removed from sid, reopening and reassigning where python-policy seems to be located now. On Tue, 2022

Re: Wiki: Debian Python Policy docu not on team site

Hi, I added in the Wiki [0], the link to the python3-defaults docs and policy [1]. Please review it. [0] https://wiki.debian.org/Teams/PythonTeam#preview [1] https://www.debian.org/doc/packaging-manuals/python-policy/ Cheers Emmanuel

Re: Wiki: Debian Python Policy docu not on team site

Hi! On Fri, Oct 1, 2021 at 7:43 AM wrote: > Hello, > > this is about the wiki page of that team. > https://wiki.debian.org/Teams/PythonTeam > > I accidentally found the "Debian Python Policy documentation". > https://www.debian.org/doc/packaging-manuals/python-pol

Re: Questions around the python-policy document

Hi Fabrice, Fabrice BAUZAC-STEHLY writes: > Hello Debian-Python, > > I have a few questions regarding the Python Policy: > https://www.debian.org/doc/packaging-manuals/python-policy/ > > - Is there a Debian package for reading it offline? (apparently not) > > - Who

Questions around the python-policy document

Hello Debian-Python, I have a few questions regarding the Python Policy: https://www.debian.org/doc/packaging-manuals/python-policy/ - Is there a Debian package for reading it offline? (apparently not) - Who maintains this document: is it the Policy team, the Python team? - Where

Re: Bug#943666: python3: Update Python Policy for removal of the Python 2 stack

Le mer. 6 nov. 2019 à 23:49, Matthias Klose a écrit : > > On 06.11.19 22:04, Nicholas D Steeves wrote: > > Brian May writes: > >> Or maybe even expand as two bullet points: > >> > >> - Do not remove python-foo-doc. > >> - Do not rename it to python3-foo-doc. > >> > >> I think this makes it very

Re: Bug#943666: python3: Update Python Policy for removal of the Python 2 stack

On 06.11.19 22:04, Nicholas D Steeves wrote: Brian May writes: Stéphane Blondon writes: Perhaps there is a doubt how to read it? - do not (remove python-foo-doc or rename it to python3-foo-doc) - (do not remove python-foo-doc) or (rename it to python3-foo-doc) Would it be better if we

Re: Bug#943666: python3: Update Python Policy for removal of the Python 2 stack

Brian May writes: > Stéphane Blondon writes: > >> Perhaps there is a doubt how to read it? >> - do not (remove python-foo-doc or rename it to python3-foo-doc) >> - (do not remove python-foo-doc) or (rename it to python3-foo-doc) >> >> Would it be better if we remove the indentation and use this

Re: Bug#943666: python3: Update Python Policy for removal of the Python 2 stack

Stéphane Blondon writes: > Perhaps there is a doubt how to read it? > - do not (remove python-foo-doc or rename it to python3-foo-doc) > - (do not remove python-foo-doc) or (rename it to python3-foo-doc) > > Would it be better if we remove the indentation and use this sentence(?): > if

Re: Bug#943666: python3: Update Python Policy for removal of the Python 2 stack

On 03.11.19 15:09, Neil Williams wrote: On Sun, 3 Nov 2019 15:00:17 +0100 Matthias Klose wrote: [discussing this outside the bug report on the ML] On 03.11.19 14:39, Neil Williams wrote: Actually, that's a good catch. I was mixing up the defaults package with the general advice on python3

Re: Bug#943666: python3: Update Python Policy for removal of the Python 2 stack

On Sun, 3 Nov 2019 15:00:17 +0100 Matthias Klose wrote: > [discussing this outside the bug report on the ML] > > On 03.11.19 14:39, Neil Williams wrote: > > Actually, that's a good catch. I was mixing up the defaults package > > with the general advice on python3 migration to not remove > >

Re: Bug#943666: python3: Update Python Policy for removal of the Python 2 stack

[discussing this outside the bug report on the ML] On 03.11.19 14:39, Neil Williams wrote: Actually, that's a good catch. I was mixing up the defaults package with the general advice on python3 migration to not remove python-foo-doc just to rename it to python3-foo-doc. where did you read

Bug#943666: python3: Update Python Policy for removal of the Python 2 stack

Package: python3 Version: 3.7.5-1 Severity: normal As discussed on IRC and alongside the post to debian-devel-announce, please review and include this amendment to the Debian Python Policy to cover the removal of the Python 2 stack as outlined at https://wiki.debian.org/Python/2Removal https

Re: Remove wiki version of the python policy?

https://wiki.debian.org/Python/Policy has been updated/cleaned up. Sorry it took so long. Joseph On Mon, May 14, 2018 at 10:50 PM, Ben Finney <bign...@debian.org> wrote: > Joseph Herlant <herla...@gmail.com> writes: > >> Hi, >> >> On Mon, May 14, 2018, 10:

Re: Remove wiki version of the python policy?

Scott Kitterman <deb...@kitterman.com> writes: > On Monday, May 14, 2018 10:55:36 AM Joseph Herlant wrote: > > Hi guys, > > > > I noticed that https://wiki.debian.org/Python/Policy is full of > > obsolete ways to do. > > Is it worth updatin

Re: Remove wiki version of the python policy?

On Monday, May 14, 2018 10:55:36 AM Joseph Herlant wrote: > Hi guys, > > I noticed that https://wiki.debian.org/Python/Policy is full of > obsolete ways to do. > Is it worth updating it or should I just remove everything there and > redirect to https://www.debian.org/doc/packag

Remove wiki version of the python policy?

Hi guys, I noticed that https://wiki.debian.org/Python/Policy is full of obsolete ways to do. Is it worth updating it or should I just remove everything there and redirect to https://www.debian.org/doc/packaging-manuals/python-policy/ ? It's ranked 3rd in Google when looking for "Debian P

PyPI wheels (was Re: Python Policy)

On Oct 21, 2015, at 08:47 PM, Brian May wrote: >in one case this is because upstream have only supplied a *.whl >file on Pypi. I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads. There is talk about source wheels, and if that happens we'll probably have to adjust our tools

Re: PyPI wheels (was Re: Python Policy)

On 2015-10-21 09:31:04 -0500 (-0500), Ian Cordasco wrote: > On Wed, Oct 21, 2015 at 8:58 AM, Barry Warsaw wrote: > > On Oct 21, 2015, at 08:47 PM, Brian May wrote: > > > >>in one case this is because upstream have only supplied a *.whl > >>file on Pypi. > > > > I'm *really*

Re: PyPI wheels (was Re: Python Policy)

On Wed, Oct 21, 2015 at 8:58 AM, Barry Warsaw wrote: > On Oct 21, 2015, at 08:47 PM, Brian May wrote: > >>in one case this is because upstream have only supplied a *.whl >>file on Pypi. > > I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads. I'm not sure

Re: Typo in Python Policy

On Tuesday, May 21, 2013 11:05:30 PM Reuben Thomas wrote: Near the start of Chapter 1, Section 1.1: implmentation → implementation Checked against 0.9.4.2. Fixed in the VCS for the next python-defaults upload. Thanks, Scott K -- To UNSUBSCRIBE, email to

Re: RFC: Adding discussion about required versions to Python policy

, then you still need to specify (in this example) X-Python3-Version. This is true, but I'm not sure why Python Policy needs to talk about this. If it does, then probably appendix B would be the correct place. Or a footnote. In general, how X(S)P(3)V is translated to dependency on python(3

Re: RFC: Adding discussion about required versions to Python policy

* Scott Kitterman deb...@kitterman.com, 2012-03-19, 09:29: The generated minumum dependency may be different than the lowest version currently supported. In such cases, X-Python-Version must still be specified if the generated dependency is not sufficient. [...] I think something like my first

RFC: Clarifying version specific depends/provides in Python policy

I've attached a patch (it's built on the last one I sent) that attempts to clarify policy around packages that only work with specific versions of Python/Python3. Here's what I attempted to do: - Changed should support the default version to should support all supported versions. - Dropped

RFC: Adding discussion about required versions to Python policy

3 3.2 need this specifed in X-Python3-Version. I took a stab at adding some words to the Python policy to explain this. Comments please (diff attached). Scott K--- python-policy.txt 2012-03-16 23:29:14.384401914 -0400 +++ python-policy.new.txt 2012-03-16 23:46:06.460372010 -0400 @@ -398,16

Re: Final updates for this Python Policy revision

On Sun, Dec 13, 2009 at 12:41 AM, Christoph Egger christoph.eg...@gmx.de wrote: anatoly techtonik schrieb: Questions like Debian Python Policy is all about GPL. Do I have to release my Python package under GPL?. Most people (as you clearly expressed) don't care, so upstream maintainers would

Re: Final updates for this Python Policy revision

please move your discussion to private or -legal -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to

Re: Final updates for this Python Policy revision

notice doesn't stay in the source then and instead appear in binary form, but it seems ok. BTW, where is the link to Debian Python Policy source in http://www.debian.org/doc/packaging-manuals/python-policy/ ? Shouldn't it be mentioned in documentation? 1. What am I free to do with with GPL'ed

Move GPL discussion elsewhere (was: Python Policy)

Quoting anatoly techtonik techto...@gmail.com: Given that people are tired of discussing things they've already decided for themselves I CC this to debian-legal. Addendum: Given that some Debian documents are released under the terms of the GPL (e.g. our release notes), this discussion has

Re: Final updates for this Python Policy revision

anatoly techtonik techto...@gmail.com writes: On Sat, Dec 12, 2009 at 12:22 PM, Ben Finney ben+deb...@benfinney.id.au wrote: Why is it ridiculous? Is it any more ridiculous to put a policy document under GPL than any other document? It is in the same ridiculous for other document. It is

Re: Final updates for this Python Policy revision

. On Sat, Dec 12, 2009 at 6:03 AM, Scott Kitterman deb...@kitterman.com wrote: I think we are at the point where the proposed update to the Python Policy is clearly more relevant and better than what is currently published.  Once this is done, we can work on refinements.  Loïc Minier (lool

Re: Final updates for this Python Policy revision

anatoly techtonik techto...@gmail.com writes: The policy is under GPL license which is kind of ridiculous to prevent citing Debian Policy in private talks. Why is it ridiculous? Is it any more ridiculous to put a policy document under GPL than any other document? I imagine people discussing

Re: Final updates for this Python Policy revision

Ben Finney schrieb: anatoly techtonik techto...@gmail.com writes: The policy is under GPL license which is kind of ridiculous to prevent citing Debian Policy in private talks. Why is it ridiculous? Is it any more ridiculous to put a policy document under GPL than any other document?

Re: Final updates for this Python Policy revision

On Sat, 2009-12-12 at 14:27 +0100, Bastian Venthur wrote: Ben Finney schrieb: anatoly techtonik techto...@gmail.com writes: The policy is under GPL license which is kind of ridiculous to prevent citing Debian Policy in private talks. Why is it ridiculous? Is it any more ridiculous

Re: Final updates for this Python Policy revision

Omer Zak schrieb: On Sat, 2009-12-12 at 14:27 +0100, Bastian Venthur wrote: Ben Finney schrieb: anatoly techtonik techto...@gmail.com writes: The policy is under GPL license which is kind of ridiculous to prevent citing Debian Policy in private talks. Why is it ridiculous? Is it any more

Re: Final updates for this Python Policy revision

I wouldn't go so far and see documentation as software. Apart from that I agree that it is important to clarify what one can do with this documentation (quote, modify, redistribute, etc.) and under which rules this has to happen. For example, when I quote a paragraph of the documentation in

Re: Final updates for this Python Policy revision

Hello, The policy is under GPL license which is kind of ridiculous to prevent citing Debian Policy in private talks. I imagine people discussing those folks at Debian. Have you heard - they've changed you-know-what to make packaging easier. =) Is there any license that more clearly states

Re: Final updates for this Python Policy revision

Policy clear without additional consulting from Debian lawyers. I understand that most of us do not want to deal with these issues, but it will only do good if people won't have any questions after reading the policy. Questions like Debian Python Policy is all about GPL. Do I have to release my

Re: Final updates for this Python Policy revision

. The point is to make Python Policy clear without additional consulting from Debian lawyers. I understand that most of us do not want to deal with these issues, but it will only do good if people won't have any questions after reading the policy. Questions like Debian Python Policy is all

Re: RFC: Proposed updates to the Python Policy to reflect current practices

Hi Loïc! Loïc Minier wrote: Require the python- prefix for public modules This would mean we'd need to split e.g. python-gtk2 into five. Do we really want that? The should wording allowed one to not do it in special cases. I'm not saying we shouldn't change it, but we should make sure we're

Re: RFC: Proposed updates to the Python Policy to reflect current practices

On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote: Require the python- prefix for public modules This would mean we'd need to split e.g. python-gtk2 into five. Do we really want that? The should wording allowed one to not do it in special cases. I'm not saying we shouldn't change it,

Re: RFC: Proposed updates to the Python Policy to reflect current practices

On Tue, Dec 08, 2009, Jakub Wilk wrote: + versions explicitely. You could fix that typo if you are at it. Thanks; I've spell checked the whole document and came up with the attached patch, Spell check fixes. -- Loïc Minier From ee2c89e0b24b2deff74ad35d59a8ca4a9f936ecf Mon Sep 17

Re: RFC: Proposed updates to the Python Policy to reflect current practices

On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote: This would mean we'd need to split e.g. python-gtk2 into five. Do we really want that? The should wording allowed one to not do it in special cases. I'm not saying we shouldn't change it, but we should make sure we're aware of all the

Re: RFC: Proposed updates to the Python Policy to reflect current practices

Loïc Minier wrote: On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote: This would mean we'd need to split e.g. python-gtk2 into five. Do we really want that? The should wording allowed one to not do it in special cases. I'm not saying we shouldn't change it, but we should make sure we're

Re: RFC: Proposed updates to the Python Policy to reflect current practices

* Loïc Minier l...@dooz.org, 2009-12-11, 12:34: url id=http://www.gnu.org/copyleft/gpl.html; - name=The GNU Public Licence. + name=The GNU Public License. That should read: The GNU General Public License. - explicitly use the versioned interpreter name +

Re: RFC: Proposed updates to the Python Policy to reflect current practices

On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote: Looks fine to me, but 3.1 needs to be updated too since it currently says that a package that needs `foo' must depend on `python-foo', which may not be correct anymore with this patch. Ack -- Loïc Minier From

Re: RFC: Proposed updates to the Python Policy to reflect current practices

Loïc Minier wrote: On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote: Looks fine to me, but 3.1 needs to be updated too since it currently says that a package that needs `foo' must depend on `python-foo', which may not be correct anymore with this patch. Ack Looks good, thanks!

Re: RFC: Proposed updates to the Python Policy to reflect current practices

On Fri, Dec 11, 2009 at 11:04:32AM +0100, Loïc Minier wrote: On Wed, Dec 09, 2009, Luca Falavigna wrote: I entirely read the 1.9.0.0 draft, I've got some thoughts on it. Thanks for your review, I'm attaching the following new patches: s/binary/interpreter for /usr/bin/python* I think

Re: RFC: Proposed updates to the Python Policy to reflect current practices

2009/12/9 Loïc Minier l...@dooz.org: On Wed, Dec 09, 2009, Dmitrijs Ledkovs wrote: Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website?  Concerning the Python Policy, it's currently not handled in any VCS, so  I created

Re: RFC: Proposed updates to the Python Policy to reflect current practices

On Fri, Dec 11, 2009, Steve Langasek wrote: I think this is a policy regression, actually. The fact that /usr/bin/python2.x is a binary, and /usr/bin/python is a symlink pointing to a binary, is not irrelevant - we certainly don't want someone to get the idea that it's ok to replace either of

Re: RFC: Proposed updates to the Python Policy to reflect current practices

On Fri, Dec 11, 2009, Dmitrijs Ledkovs wrote: 2009/12/9 Loïc Minier l...@dooz.org: On Wed, Dec 09, 2009, Dmitrijs Ledkovs wrote: Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website?  Concerning the Python Policy

Final updates for this Python Policy revision

I think we are at the point where the proposed update to the Python Policy is clearly more relevant and better than what is currently published. Once this is done, we can work on refinements. Loïc Minier (lool) did attempt to send the proposed final patch set to the list and it has gotten

Re: RFC: Proposed updates to the Python Policy to reflect current practices

Le mardi 08 décembre 2009 à 21:24 +0100, Loïc Minier a écrit : The goal of this set of patches is only to reflect what's de facto being done in the archive, and update various bit-rotted sections of the Python Policy. It's only a first step, but also a prerequisite for other changes

Re: RFC: Proposed updates to the Python Policy to reflect current practices

On Wed, Dec 09, 2009, Dmitrijs Ledkovs wrote: Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website? Concerning the Python Policy, it's currently not handled in any VCS, so I created a private git repo from the uploads

Re: RFC: Proposed updates to the Python Policy to reflect current practices

Il giorno Tue, 8 Dec 2009 21:24:05 +0100 Loïc Minier l...@dooz.org ha scritto: To resurrect the Python Policy as a document reflecting required and recommended Python packaging practices, we prepared a set of patches. Many thanks for that! I entirely read the 1.9.0.0 draft, I've got some

Re: RFC: Proposed updates to the Python Policy to reflect current practices

On Tue, Dec 08, 2009 at 09:24:05PM +0100, Loïc Minier wrote: To resurrect the Python Policy as a document reflecting required and recommended Python packaging practices, we prepared a set of patches. We started in private to provide a complete set of changes and avoid flames as much

Re: RFC: Proposed updates to the Python Policy to reflect current practices

: debian-pyt...@ldo ]        Hi all,  To resurrect the Python Policy as a document reflecting required and  recommended Python packaging practices, we prepared a set of patches.  We started in private to provide a complete set of changes and avoid  flames as much as possible, but now we'd like

Re: RFC: Proposed updates to the Python Policy to reflect current practices

Luca Falavigna dktrkr...@debian.org writes: --- | 1.2. Main packages | |At any time, the `python' package must ensure that the binary |`/usr/bin/python' is provided. --- This is currently not a binary, but a relative symlink pointing to ./pythonX.Y (where X.Y is the current

Re: RFC: Proposed updates to the Python Policy to reflect current practices

* Loïc Minier l...@dooz.org, 2009-12-08, 21:24: + versions explicitely. You could fix that typo if you are at it. (Sorry for nitpicking!) -- Jakub Wilk signature.asc Description: Digital signature

Re: RFC: Proposed updates to the Python Policy to reflect current practices

2009/12/8 Loïc Minier l...@dooz.org:  [ MFT: debian-pyt...@ldo ]        Hi all,  To resurrect the Python Policy as a document reflecting required and  recommended Python packaging practices, we prepared a set of patches.  We started in private to provide a complete set of changes and avoid

Re: RFC: Proposed updates to the Python Policy to reflect current practices

Dmitrijs Ledkovs dmitrij.led...@gmail.com (09/12/2009): Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website? $ debcheckout debian-policy declared git repository at git://git.debian.org/git/dbnpolicy/policy.git git clone

Re: Work on a current Debian Python policy (was: Lintian warnings for Python packaging?)

Le lundi 02 novembre 2009 à 21:22 +1100, Ben Finney a écrit : Is there a silent Debian Python policy drafter out there who would like to step forward? Or is this work now moribund? Bug reports concerning the Python policy have been silently ignored. I’m afraid this will last as long

Re: Work on a current Debian Python policy

Josselin Mouette j...@debian.org writes: Le lundi 02 novembre 2009 à 21:22 +1100, Ben Finney a écrit : Is there a silent Debian Python policy drafter out there who would like to step forward? Or is this work now moribund? Bug reports concerning the Python policy have been silently ignored

Re: Work on a current Debian Python policy (was: Lintian warnings for Python packaging?)

On Tue, 03 Nov 2009 19:02:21 +0100 Josselin Mouette j...@debian.org wrote: Le lundi 02 novembre 2009 à 21:22 +1100, Ben Finney a écrit : Is there a silent Debian Python policy drafter out there who would like to step forward? Or is this work now moribund? Bug reports concerning the Python

Re: Work on a current Debian Python policy

Josselin Mouette j...@debian.org writes: Le lundi 02 novembre 2009 à 21:22 +1100, Ben Finney a écrit : Is there a silent Debian Python policy drafter out there who would like to step forward? Or is this work now moribund? Bug reports concerning the Python policy have been silently ignored

Re: Work on a current Debian Python policy

On Wed, Nov 4, 2009 at 2:29 AM, Ben Finney ben+deb...@benfinney.id.au wrote: (I am reading this to mean “the reference version of the Debian Python policy is in the python-defaults package”.) Okay. Clearly one way for this to improve would be for some of those bug reports to be responded

Work on a current Debian Python policy (was: Lintian warnings for Python packaging?)

Luca Falavigna dktrkr...@debian.org writes: Scott Kitterman ha scritto: Since we currently lack anything like a maintained Python policy, I think this is putting the cart before the horse. […] […] we could wait for the new policy to be drafted, I'm not sure when this will happen, though

Re: Work on a current Debian Python policy (was: Lintian warnings for Python packaging?)

On Mon, Nov 2, 2009 at 2:27 PM, Scott Kitterman deb...@kitterman.com wrote: I'm not aware of any ongoing work.  I would be willing to help work on such a thing, but we currently lack a good mechanism for developing/approving such a policy. With clear policy and precise goal you won't need

Re: Work on a current Debian Python policy (was: Lintian warnings for Python packaging?)

/approving such a policy. With clear policy and precise goal you won't need approving mechanism to see if they work for defined set of cases or not. ... Yes and we have neither right now. Writing stuff on a wiki won't change that. Until we have a legitimate Python policy, all we have to base

Verifying module dependencies (Was: [Help] Failed to apply new Python policy to GNUmed packages)

On Sat, 28 Mar 2009, Emilio Pozuelo Monfort wrote: I got an error that mx.DateTime can't be imported, so you probably need to depend on python-egenix-mxdatetime). Thanks to Emilio I was able to fix the gnumed-client package which was in fact lacking the python-egenix-mxdatetime build

Re: [Help] Failed to apply new Python policy to GNUmed packages

On Mon, 30 Mar 2009, Emilio Pozuelo Monfort wrote: I think pysupport does this for you. When the default interpreter changes, it will regenerate all the .pyc files for the new one. This lets me relax a bit more, but hmmm, I'm not fully convinced ... And FWIW I've just noticed that your

Re: [Help] Failed to apply new Python policy to GNUmed packages

On Mon, Mar 30, 2009 at 07:27:59AM +0200, RKI Andreas wrote: While it is tempting to slip in not strictly needed improvements into a bugfix it is usually - as is quite evident here - a road down which dragons live. Don't. Well, I didn't in the first place (look at 0.3.12 package). But

Re: [Help] Failed to apply new Python policy to GNUmed packages

Le lundi 30 mars 2009 à 12:18 +0200, Karsten Hilbert a écrit : For what it's worth the gnumed.py outermost Python script sayeth: #!/usr/bin/env python and, then, even that is ignored because the /usr/bin/gnumed shell script calls gnumed.py via python -m. Which means using the default

Re: [Help] Failed to apply new Python policy to GNUmed packages

Le lundi 30 mars 2009 à 12:26 +0200, Karsten Hilbert a écrit : - use Gnumed.pth in site-packages/ (which higher wizards around here discourage us to do) Please don’t! This completely defeats the point of shipping packages in a private directory. - link /usr/share/gnumed/Gnumed into

Re: [Help] Failed to apply new Python policy to GNUmed packages

Le dimanche 29 mars 2009 à 20:46 +0200, Karsten Hilbert a écrit : I believe Andreas was wondering about the pre-compiled pyc files being installed alongside the py files. If they are stored there they can only be precompiled by one particular Python version at a time. This made us wonder what,

Re: [Help] Failed to apply new Python policy to GNUmed packages

On Mon, Mar 30, 2009 at 02:18:31PM +0200, Josselin Mouette wrote: - modify sys.path inside gnumed.py appropriately (which I disapprove of as it means moving platform specific code from platform specific layers into platform-agnostic Python code) This one is my favorite;

Re: [Help] Failed to apply new Python policy to GNUmed packages

Le lundi 30 mars 2009 à 14:50 +0200, Karsten Hilbert a écrit : On Mon, Mar 30, 2009 at 02:18:31PM +0200, Josselin Mouette wrote: - modify sys.path inside gnumed.py appropriately (which I disapprove of as it means moving platform specific code from platform specific layers

Re: [Help] Failed to apply new Python policy to GNUmed packages

On Mon, Mar 30, 2009 at 03:27:55PM +0200, Josselin Mouette wrote: I also tend to prefer solutions that look more robust, for example against existing PYTHONPATH variables. The rest is a matter of taste. This is (now) the relevant part in /usr/bin/gnumed: # packages which install the GNUmed

Re: [Help] Failed to apply new Python policy to GNUmed packages

On Sat, 28 Mar 2009, Emilio Pozuelo Monfort wrote: That is, you're now shipping some modules in a private location This is what I understood as recommendation in #516037. (usr/share is not in PYTHONPATH), so they are not found when you try to import them. You could ship Gnumed in

Re: [Help] Failed to apply new Python policy to GNUmed packages

That is, you're now shipping some modules in a private location This is what I understood as recommendation in #516037. Well, you are trying to solve two things at once: 1) make the python -m calling convention work 2) move GNUmed modules to a private location While, yes, this WAS

Re: [Help] Failed to apply new Python policy to GNUmed packages

For what it's worth here is my concluding suggestion in that bug thread: - My suggestion would be: - call gnumed.py with the python -m ... option if that works - this would rid us of that hardcoded path - a great thing - leave modules where they are and GNUmed finds them by

Re: [Help] Failed to apply new Python policy to GNUmed packages

Hiya, Andreas Tille wrote: On Sat, 28 Mar 2009, Emilio Pozuelo Monfort wrote: That is, you're now shipping some modules in a private location This is what I understood as recommendation in #516037. Yes, that's recommended, but it's not a requirement. Anyway, you almost got it!

Re: [Help] Failed to apply new Python policy to GNUmed packages

That is, you're now shipping some modules in a private location This is what I understood as recommendation in #516037. Yes, that's recommended, but it's not a requirement. Anyway, you almost got it! (usr/share is not in PYTHONPATH), so they are not found when you try to import

Re: [Help] Failed to apply new Python policy to GNUmed packages

Karsten Hilbert wrote: You're missing a 'export' before setting the variable (or call python in the same line you set it). Ah, thanks. Emilio, you are clearly a better expert on packaging Python code under Debian than me :-) That was shell ;) I really wonder how this new python-support

Re: [Help] Failed to apply new Python policy to GNUmed packages

0.4.x it stopped working this way - so I tried to apply the recommendations of the updated Python policy from scratch. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [Help] Failed to apply new Python policy to GNUmed packages

On Sun, 29 Mar 2009, Karsten Hilbert wrote: - My suggestion would be: - call gnumed.py with the python -m ... option if that works - this would rid us of that hardcoded path - a great thing - leave modules where they are and GNUmed finds them by default - if the Debian package

Re: [Help] Failed to apply new Python policy to GNUmed packages

On Sun, 29 Mar 2009, Emilio Pozuelo Monfort wrote: You're missing a 'export' before setting the variable (or call python in the same line you set it). Uhm - stupid me. That's a beginners fault ... :-( In the first releases of gnumed-client package I used Gnumed.pth but dropped this since I

[Help] Failed to apply new Python policy to GNUmed packages

Hi, I tried to implement the Python policy [1] using python-support to the new GNUmed packages but failed. If I try the basic essence of the /usr/bin/gnumed script I get: $ python -m Gnumed.wxpython.gnumed Traceback (most recent call last): File /usr/lib/python2.5/runpy.py, line 85

Re: Moving towards a single Python policy

On Wed, Jan 23, 2008 at 04:48:31PM +, Noah Slater wrote: I am new contributer to the Python Modules Team and I wanted to express that I find the presence of two policy manuals confusing. Someone pointed me off list to this email:

Moving towards a single Python policy

/doc/packaging-manuals/python-policy/ To reduce confusion and move towards a single unified policy, what is stopping us from moving srivasta's policy to the proper location and blessing it official while, perhaps, archiving the old policy for access to those explicitly looking for it? Thoughts

Re: Proposed update to the python policy

On Tue, May 01, 2007 at 12:17:33AM +0100, Floris Bruynooghe wrote: Hi On Wed, Mar 28, 2007 at 08:39:42PM +0200, Pierre Habouzit wrote: wrt the current thingie, I may have a proposal ready soon, I just need to polish the details, and look how hard it would be to upgrade the dh_py* tools

Re: Proposed update to the python policy

Hi On Wed, Mar 28, 2007 at 08:39:42PM +0200, Pierre Habouzit wrote: wrt the current thingie, I may have a proposal ready soon, I just need to polish the details, and look how hard it would be to upgrade the dh_py* tools to them. Well, I've a hard week of paid work ahead, so I don't expect

Re: Proposed update to the python policy

While the discussion is still ongoing about the current keyword, it seems that everyone agrees with the other changes which are only loosely related. Can we proceed with these, until we agree on how current should be replaced? -- .''`. : :' : We are debian.org. Lower your prices, surrender

Re: Proposed update to the python policy

[Josselin Mouette, 28.03.2007] While the discussion is still ongoing about the current keyword, it seems that everyone agrees with the other changes which are only loosely related. Can we proceed with these, until we agree on how current should be replaced? IMHO, yes -- -=[ Piotr

Re: Proposed update to the python policy

On Fri, Mar 23, 2007 at 10:39:45AM +0100, Piotr Ożarowski wrote: Ugh, it should fail *regardless* of the existence of python2.X-dev. Why would you ever call it current if it's building for something that *isn't* the current version of python? A package should only be called python-foo if

Re: Proposed update to the python policy

[Steve Langasek, 24.03.2007] On Fri, Mar 23, 2007 at 10:39:45AM +0100, Piotr Ożarowski wrote: I couldn't set python in hashbang (as I said before: gaupol will not work with python2.3). Package was build when python2.3 was default so hashbang was set to python2.4. Now when python2.3 was

Re: Proposed update to the python policy

[Pierre Habouzit, 22.03.2007] On Thu, Mar 22, 2007 at 10:13:40PM +0100, Piotr Ożarowski wrote: [Josselin Mouette, 22.03.2007] Le jeudi 22 mars 2007 à 19:56 +0100, Pierre Habouzit a écrit : Just nitpicking: the dh_ tool doesn't need to know that, as it can guess it from what

Re: Proposed update to the python policy

On Fri, Mar 23, 2007 at 09:58:18AM +0100, Piotr Ożarowski wrote: - relying on Build-Depends to indicate whether a package builds current or all doesn't seem to leave a way to differentiate between packages that follow the new policy and really /are/ binNMUable, from those that don't

  1   2   3   >