Hi Federico (2024.06.03_16:11:27_+)
> I was in the DPMT back when it was on Alioth and I would like to join
> it again. My Salsa login is "federico".
Added, welcome back
Stefano
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Hello,
I was in the DPMT back when it was on Alioth and I would like to join
it again. My Salsa login is "federico".
I have read the policy and I accept it:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
Thank you!
--
Federico
On Thu, May 25, 2023 at 12:19:00PM +, TopologicRose wrote:
> Hi,
> want to contribute a Python package which called pyvis
> (https://pyvis.readthedocs.io/en/latest/index.html) for APT.
> A friend of mine works with it and wants it as a Debian package instead of
> pip.
Start at https://mentors
Hey,
File an ITP bug for it against wnpp pseudo package and start to package it on
https://mentors.debian.org
Ask here after you filed the RFS.
Sincerely
در ۲۵ مهٔ ۲۰۲۳ ۱۲:۱۹:۰۰ (UTC)، TopologicRose
نوشت:
>Hi,
>want to contribute a Python package which called pyvis
>(https://pyvis.readthedo
Hi,
want to contribute a Python package which called pyvis
(https://pyvis.readthedocs.io/en/latest/index.html) for APT.
A friend of mine works with it and wants it as a Debian package instead of pip.
Best regards,
Thanh-Viet Nguyen
Preamble 'foo' and 'bar' are placeholders.
( https://en.wikipedia.org/wiki/Metasyntactic_variable )
On Tue, Apr 07, 2020 at 08:13:02PM +0200, Alex Mestiashvili wrote:
> Hi Debian Python folks,
>
> Is there a good entry point for a newbie who wants to package a python
> module? I am looking for
Hi Samuel,
I want make a Talks for PyConAr (Argentina). I send a
mail https://lists.debian.org/debian-python/2019/08/msg00158.html
asking about my ideas.
So I will send my proposal with that ideas. If you (and the community)
have some comments or advices, please let me know. They are
welcomes :-)
Hello,
For information, PyConFR (in french) will take place in Bordeaux from
october 31th to november 3rd. There will most probably be an workshop
on upt (universal packaging tool, https://framagit.org/upt/upt)
Samuel
On Apr 25, 2015, at 03:42 PM, Tomasz Buchert wrote:
> * the library provides a program as /usr/bin/pyenigma.py; should I:
>(a) declare another binary package (say, pyenigma) with it and
>make it depend on python3-enigma or (b) leave it as it is now, a
>part of the library?
>(a) se
On Saturday, April 25, 2015 03:42:29 PM Tomasz Buchert wrote:
> Hi guys,
> I'm preparing a package for this library:
> https://bitbucket.org/bgneal/enigma/ It's rather trivial (see
> alioth:/git/collab-maint/python-enigma.git), but I have two questions that
> remain:
>
> * the library provides a
Hi guys,
I'm preparing a package for this library: https://bitbucket.org/bgneal/enigma/
It's rather trivial (see alioth:/git/collab-maint/python-enigma.git),
but I have two questions that remain:
* the library provides a program as /usr/bin/pyenigma.py; should I:
(a) declare another binary p
On 31 March 2015 at 17:46, Zygmunt Krynicki
wrote:
>
> Is there a way to use git but build with sbuild. I kind of don't want
> to go back to pbuilder and IIRC git-buildpackage requires it.
I build packages with --git-builder=sbuild all the time, and haven't
had any issues. You can also build sour
On Mar 31, 2015, at 05:46 PM, Zygmunt Krynicki wrote:
>Is there a way to use git but build with sbuild. I kind of don't want
>to go back to pbuilder and IIRC git-buildpackage requires it.
>> gitbp is aliased to `git-buildpackage --git-ignore-new --git-export=WC -S
>> -us -uc'
Notice the -S? I p
Is there a way to use git but build with sbuild. I kind of don't want
to go back to pbuilder and IIRC git-buildpackage requires it.
On Tue, Mar 31, 2015 at 5:43 PM, Barry Warsaw wrote:
> On Mar 31, 2015, at 04:48 PM, Antoine Musso wrote:
>
>>I have only been introduced to git-buildpackage and usi
On Mar 31, 2015, at 08:23 PM, Balasankar C wrote:
>I saw a mention about inter-operability of git-dpm and git-bp in the
>link you provided[1]. What is the current status of this
>inter-operability?
I haven't seen any discussion of this in a long time. I think it was
happening on debian-devel.
C
On Mar 31, 2015, at 04:48 PM, Antoine Musso wrote:
>I have only been introduced to git-buildpackage and using Jenkins to more or
>less automatically build them when proposing a patch or a change is merged.
Really, git-dpm is just the patch manager. There are a few others, but I
found git-dpm to
Breaking from another thread
On 31/03/15 15:57, Barry Warsaw wrote:
The team still officially supports only Subversion, but we have been
experimenting with switching to git.
https://wiki.debian.org/Python/GitPackaging
I personally favor and advocate git-dpm, but this has not yet been decided b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Barry,
> * Do we adopt git-dpm or something else?
I saw a mention about inter-operability of git-dpm and git-bp in the
link you provided[1]. What is the current status of this
inter-operability? Are there any roadblocks for the same?
AFAIK, both
On Mar 31, 2015, at 04:04 PM, Zygmunt Krynicki wrote:
>Barry the import script looks pretty cool.
Thanks!
>Any chance to package it and bless it as the official conversion script?
Either that or donate it to the git-dpm project. Either way is cool with me,
though I'd love for it to get more te
Barry the import script looks pretty cool.
Any chance to package it and bless it as the official conversion script?
Best regards
ZK
On Tue, Mar 31, 2015 at 3:57 PM, Barry Warsaw wrote:
> On Mar 31, 2015, at 01:14 PM, Balasankar C wrote:
>
>>One more doubt. Where are new packages uploaded to in
On Mar 31, 2015, at 01:14 PM, Balasankar C wrote:
>One more doubt. Where are new packages uploaded to in Python Modules
>Team? Is there a git repo or should I upload to Debian Mentors?
The team still officially supports only Subversion, but we have been
experimenting with switching to git.
https
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
> The repos creation would be (with an alioth account in the team
> project)
>
> ssh git.debian.org cd /git/python-modules ./setup-repository
> 'python-wget' 'python-wget packaging'
Thanks for the detailed instructions. I believe it is ok if I
On 31/03/15 09:44, Balasankar C wrote:
Hi,
One more doubt. Where are new packages uploaded to in Python Modules
Team? Is there a git repo or should I upload to Debian Mentors? I am
asking this because, in Ruby team, the uploads usually happen to the
git repos created inside pkg-ruby-extras folder
W dniu 31.03.2015 o 09:44, Balasankar C pisze:
Hi,
One more doubt. Where are new packages uploaded to in Python Modules
Team? Is there a git repo or should I upload to Debian Mentors? I am
asking this because, in Ruby team, the uploads usually happen to the
git repos created inside pkg-ruby-ex
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
One more doubt. Where are new packages uploaded to in Python Modules
Team? Is there a git repo or should I upload to Debian Mentors? I am
asking this because, in Ruby team, the uploads usually happen to the
git repos created inside pkg-ruby-extra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Thanks. Will correct them.
- --
Regards
Balasankar C
http://balasankarc.in
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCgAGBQJVGjmTAAoJEJbtq5sua3Fx+/MIAJ0cuM0i5RRoLqbOqkMXUQcQ
KGHL3Esc+n8mkriZ15KnYIoiEDItxItanHY+B4bTo2hHIkW067Xdb+KT7lDk
> My name is Balasankar C. I am writing a module in Python and want to
> package that for Debian. So, just to understand how packaging in python
> work, I decided to package the module 'wget'. From my knowledge in
> Ruby gem
> packaging, I tried to package wget and pushed the result to
> https://gi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
My name is Balasankar C. I am writing a module in Python and want to
package that for Debian. So, just to understand how packaging in python
work, I decided to package the module 'wget'. From my knowledge in
Ruby gem
packaging, I tried to packag
On Sep 21, 2010, at 03:02 PM, Clint Byrum wrote:
>In the java world, they use maven because it handles this for them.
>They create a maven spec file that says "I need libX, libY, and
>libZ (v1.1)". maven, during the build, goes out and finds libX and
>libY's latest versions, then finds the closest
[Clint Byrum, 2010-09-22]
> On Sep 21, 2010, at 3:26 AM, Piotr Ożarowski wrote:
> > but this way you cannot `import foo` anymore, you'll have to change all
> > import lines (s/foo/foo2/) even if your code is not affected by API change
>
> Because languages like python do runtime call resolution, t
On Sep 21, 2010, at 3:26 AM, Piotr Ożarowski wrote:
> [Simon McVittie, 2010-09-21]
>> On Tue, 21 Sep 2010 at 10:30:33 +0200, Piotr Ożarowski wrote:
>>> I see only one sane way to fix the problem - changing Python interpreter
>>> to recognize API from filenames, like foo.1.py foo.2.py foo.2.3.py
>
[Barry Warsaw, 2010-09-21]
> On Sep 21, 2010, at 10:30 AM, Piotr Ożarowski wrote:
> >I see only one sane way to fix the problem - changing Python
> >interpreter to recognize API from filenames, like foo.1.py foo.2.py
> >foo.2.3.py (with `import foo <= 2` as valid syntax) and let upstream
> >authors
On Sep 21, 2010, at 10:30 AM, Piotr Ożarowski wrote:
>[Robert Collins, 2010-09-20]
>> Path to a solution: use an API marker analgous to the ABI markers C
>> libraries have. Incompatible changes to a package bump the package
>> *name*. e.g.
>> python-zope.publication2.3 to python-zope.publication2.
[Simon McVittie, 2010-09-21]
> On Tue, 21 Sep 2010 at 10:30:33 +0200, Piotr Ożarowski wrote:
> > I see only one sane way to fix the problem - changing Python interpreter
> > to recognize API from filenames, like foo.1.py foo.2.py foo.2.3.py
> > (with `import foo <= 2` as valid syntax) and let upstr
On Tue, 21 Sep 2010 at 10:30:33 +0200, Piotr Ożarowski wrote:
> I'm not sure we should try to solve this. IMHO we should try to convince
> upstreams that breaking API/ABI so often is a bad thing instead.
... and that when they do, they need to rename the module with a version
number, just like C u
[Piotr Ożarowski, 2010-09-21]
> [Robert Collins, 2010-09-20]
> > Path to a solution: use an API marker analgous to the ABI markers C
> > libraries have. Incompatible changes to a package bump the package
> > *name*. e.g.
> > python-zope.publication2.3 to python-zope.publication2.4
> > Compatible ch
[Robert Collins, 2010-09-20]
> Path to a solution: use an API marker analgous to the ABI markers C
> libraries have. Incompatible changes to a package bump the package
> *name*. e.g.
> python-zope.publication2.3 to python-zope.publication2.4
> Compatible changes don't:
> python-zope.publication2.3-
: Fri, 20 Aug 2010 09:22:20 +1200
From: Robert Collins
To: Barry Warsaw
Subject: Python packaging, dependencies, upstream facilities
So, I'm going to give you a use case that debian packages suck at for
python (they don't for C) and how I see a path-to-a-solution.
If you were to make
On 21/04/10 05:01, Jakub Wilk wrote:
Who is your target audience? If you want this document to be read by
packaging newbies, then this document is terribly incomplete.
That, I believe, would be because of my very limited knowledge in the
field. Although I may not have explicitly said this initia
* Umang Varma , 2010-04-18, 08:30:
My general impression is that it's yet another (very) bad piece of
documentation. Feel free to ignore my opinion however, as I'm
already prejudiced. :P
It's hard to ignore your opinion (or for that matter, that of any DD
here). When you say very bad, it is cle
On Fri, Apr 16, 2010 at 06:15:20PM +0530, Umang Varma wrote [edited]:
> A few weeks back there was a small discussion I initiated on
> #debian-python about a guide for new-comers to learn about packaging
> Python applications and modules. I decided to update, restructure
A big bravo for the effort
On 18/04/10 10:58, Angel Abad wrote:
Great work! I dont like much cdbs, but thanks for the effort
Thanks. :) DktrKranz, themill and I had discussed neutrality. That line
of discussion (looking at the IRC logs now) got lost somewhere so I
eventually chose the middle path - presenting dh7
2010/4/16 Umang Varma :
> Hi,
>
> A few weeks back there was a small discussion I initiated on #debian-python
> about a guide for new-comers to learn about packaging Python applications
> and modules. I decided to update, restructure and add to a guide on the
> Ubuntu Wiki:
> https://wiki.ubuntu.co
On 18/04/10 01:01, Jakub Wilk wrote:
My general impression is that it's yet another (very) bad piece of
documentation. Feel free to ignore my opinion however, as I'm already
prejudiced. :P
It's hard to ignore your opinion (or for that matter, that of any DD
here). When you say very bad, it is c
Hello,
* Umang Varma , 2010-04-16, 18:15:
https://wiki.ubuntu.com/PackagingGuide/Python?action=recall&rev=11
My general impression is that it's yet another (very) bad piece of
documentation. Feel free to ignore my opinion however, as I'm already
prejudiced. :P
Okay, and here are some factu
Hi,
A few weeks back there was a small discussion I initiated on
#debian-python about a guide for new-comers to learn about packaging
Python applications and modules. I decided to update, restructure and
add to a guide on the Ubuntu Wiki:
https://wiki.ubuntu.com/PackagingGuide/Python?action=r
On Tue, 03 Nov 2009 19:02:21 +0100 Josselin Mouette 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 policy have b
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 as the re
On Mon, 2 Nov 2009 16:50:00 +0300 anatoly techtonik wrote:
>On Mon, Nov 2, 2009 at 2:27 PM, Scott Kitterman 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.
>
>Wit
On Mon, Nov 2, 2009 at 2:27 PM, Scott Kitterman 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 approving mechanism
On Mon, 02 Nov 2009 21:22:47 +1100 Ben Finney
wrote:
>Luca Falavigna 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 draft
Jakub Wilk ha scritto:
>> * E: Don't hard-code {site,dist}-packages
>
> Uhm, what do you mean?
That's what we are trying to fix with
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-pyt...@lists.debian.org;tag=dist-packages
In case we missed some packages, or some NEW ones were included
Steve Langasek ha scritto:
>> * E: Don't hard-code {site,dist}-packages
>
> hard-coded where, and how will you detect this?
debian/rules and other control files such as debian/install and
debian/links.
>> * W: Build extension for every supported Python version
>
> how will you detect this?
Pa
Luca Falavigna 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.
I don't know
Scott Kitterman ha scritto:
>> * E: Don't hard-code {site,dist}-packages
>> * E: Python files in incorrect python2.?/{site,dist}-packages directory
>
> Since we currently lack anything like a maintained Python policy, I think
> this is putting the cart before the horse. Particularly any Error le
Ben Finney ha scritto:
>> * I: Place Python applications in private directory
>
> What would be the test for these cases? That is, what would Lintian
> actually check in the package to determine whether these should be
> emitted?
This is quite complex to say, I initially thought of checking for f
On Mon, Nov 02, 2009 at 12:54:04AM +0100, Luca Falavigna wrote:
> Currently, Lintian supports dozen of tags [1], but very few strictly
> related to Python packaging. I think maintainers and sponsors would
> benefit a lot if some common mistakes and suggestions are automatically
>
* Luca Falavigna , 2009-11-02, 00:54:
I propose a non comprehensive list of tags I'd like to see available:
* E: Don't hard-code {site,dist}-packages
Uhm, what do you mean?
* E: Python files in incorrect python2.?/{site,dist}-packages directory
We need this check as soon as possible.
* I:
Luca Falavigna writes:
> I propose a non comprehensive list of tags I'd like to see available:
Thank you, I think this is a good start.
> * E: Don't hard-code {site,dist}-packages
> * E: Python files in incorrect python2.?/{site,dist}-packages
> directory
> * W: Build extension for every suppor
On Mon, 2 Nov 2009 00:54:04 +0100 Luca Falavigna
wrote:
>Currently, Lintian supports dozen of tags [1], but very few strictly
>related to Python packaging. I think maintainers and sponsors would
>benefit a lot if some common mistakes and suggestions are automatically
>displayed by L
Currently, Lintian supports dozen of tags [1], but very few strictly
related to Python packaging. I think maintainers and sponsors would
benefit a lot if some common mistakes and suggestions are automatically
displayed by Lintian.
I propose a non comprehensive list of tags I'd like t
On Tue, Sep 15, 2009 at 03:21:41PM +0200, Alessandro Dentella wrote:
> On Tue, Sep 15, 2009 at 09:27:23AM +0200, Julian Andres Klode wrote:
> > On Tue, Sep 15, 2009 at 09:12:54AM +0200, Alessandro Dentella wrote:
> > > On Tue, Sep 15, 2009 at 07:02:23AM +0200, Adrian von Bidder wrote:
> > > > -> Po
Adrian von Bidder wrote:
> Reading only the first few messages:
> -> there was a BoF where something was discussed
> -> the Python Toolchain maintainer isn't doing his Job
> -> some ignore what was discussed/decided/requested/demanded at that BoF
> -> what this actually was and why is in the m
On Tuesday 15 September 2009 09.12:54 Alessandro Dentella wrote:
> there has been a fairly long thread with title 'XS-Python-Version vs
> pyversions ' some days ago, you may want to read it at:
>
> http://lists.debian.org/debian-python/2009/09/threads.html
Hmm.
Reading only the first few messa
On Tue, Sep 15, 2009 at 09:27:23AM +0200, Julian Andres Klode wrote:
> On Tue, Sep 15, 2009 at 09:12:54AM +0200, Alessandro Dentella wrote:
> > On Tue, Sep 15, 2009 at 07:02:23AM +0200, Adrian von Bidder wrote:
> > > -> Policy says I should ship my (private) modules in
> > > /usr/share/.
> > > H
On Tue, Sep 15, 2009 at 09:12:54AM +0200, Alessandro Dentella wrote:
> On Tue, Sep 15, 2009 at 07:02:23AM +0200, Adrian von Bidder wrote:
> > -> Policy says I should ship my (private) modules in /usr/share/.
> > How will Python find the modules?
>
> i guess you must patch your application to add
On Tue, Sep 15, 2009 at 07:02:23AM +0200, Adrian von Bidder wrote:
> Heyho!
>
> I'm fairly new to Python and absolutely new to packaging python stuff. So
> I'd be happy about a few comments [cc:s appreciated] or pointers to online
> resources (sorry, I'm working mostly offline, so I've not look
Heyho!
I'm fairly new to Python and absolutely new to packaging python stuff. So
I'd be happy about a few comments [cc:s appreciated] or pointers to online
resources (sorry, I'm working mostly offline, so I've not looked beyong the
python policy.)
My small application needs python3 (yes, I re
On mer, 2008-04-02 at 12:04 -0500, Steve M. Robbins wrote:
> The sequence shown in the build log indicates that no python-dev
> package is installed at all. This is due to another change made to
> support multiple python runtimes. The libboost-python-dev package
> used to depend on python-dev. N
[My knowledge of python is nearly zero - and I don't plan to subscribe
to -python]
On Wednesday 02 April 2008, Steve M. Robbins wrote:
> You might want to consider doing so; this allows you to be
> clear as to which version of python you support. Or, indeed,
> build support for both 2.4 and 2.
For the debian-python readers just joining in: the recent modification
of Boost to support multiple Python runtimes has some unintended
consequences; see bug #473973. Below are some questions for your
consideration.
On Wed, Apr 02, 2008 at 06:11:34PM +0200, Sune Vuorela wrote:
> If I ask specif
Thanks a lot to all of you, that clarified things for me!
On Wed, 16 Jan 2008 14:10:11 +0100 Josselin Mouette wrote:
> Le mercredi 16 janvier 2008 à 00:31 +0100, Eike Nicklas a écrit :
> > * Which value should the XS-Python-Version field have to ensure easy
> > transitions of future Python vers
Le mercredi 16 janvier 2008 à 00:31 +0100, Eike Nicklas a écrit :
> * Which value should the XS-Python-Version field have to ensure easy
> transitions of future Python versions? I tried using 'all', but then
> my (binary) package depended for example on python2.3-gtk2,
> python2.4-gtk2 and py
OoO En cette nuit striée d'éclairs du mercredi 16 janvier 2008, vers
02:29, Emilio Pozuelo Monfort <[EMAIL PROTECTED]> disait:
>> * For specifying supported Python versions, the policy recommends using
>> XS/B-Python, whereas the python-support documentation recommends
>> debian/pyversions. Wh
Eike Nicklas wrote:
> Hi Debian Python experts,
>
> I am currently trying to create Debian packages for a small python
> application I am writing. I thinks, this application is not yet ready
> for an official inclusion in Debian, but still, I have some questions
> about 'proper' packaging just out
Hi Debian Python experts,
I am currently trying to create Debian packages for a small python
application I am writing. I thinks, this application is not yet ready
for an official inclusion in Debian, but still, I have some questions
about 'proper' packaging just out of interest:
* For specifying
On 6/18/07, Loïc Minier <[EMAIL PROTECTED]> wrote:
(...)
My Alioth username is "lool".
Welcome to the team lool, nice to see you here.
thanks,
-- stratus
http://stratusandtheswirl.blogspot.com
> I'd like to join the Python Packaging Team to work on Louie and
> probably the other existing modules the team maintains.
>
> My Alioth username is "lool".
"User Added Successfully", welcome :-)
--
-=[ Piotr Ozarowski ]=-
-=[ http://www
sted to talk to
the Python Packaging Team.
I'd like to join the Python Packaging Team to work on Louie and
probably the other existing modules the team maintains.
My Alioth username is "lool".
Thanks,
--
Loïc Minier
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a sub
a
>package like pygtk2 comes to mind, having many rdepends).
>We still do have the limitation, that every python module depending
>on a pythonX.Y-foo binary-arch package cannot use the packaging
>infrastructure.
Two comments here. First, I don't think all python exten
On 2006-02-04T10:13+0900 Sanghyeon Seo wrote:
> # Python distutils script for Debian package
> # Seo Sanghyeon
>
> from distutils.core import setup
> setup(packages=[
> 'simpleparse',
> 'simpleparse.common',
> 'simpleparse.xml',
> ])
>
> That's all.
>
> setup.py is a good idea in
On Sat, 2006-02-04 at 10:13 +0900, Sanghyeon Seo wrote:
> But in case of feedparser and web.py, aren't they just a single file?
> I can't blame upstream for not interested in setup.py. I'm not sure
> what Joe Wreschnig means when he says it's "unmanagable". I think
> simple dh_install is fine for a
2006/2/4, Kai Hendry <[EMAIL PROTECTED]>:
> I am new to python packaging and I'm a little concerned about this
> 'setup.py'.
>
> It duplicates debian/control. So whilst maintaining one I have to worry
> about keeping debian/control and that setup.py in sync. Arg
I've used the feedparser package as a starting point for packaging
http://webpy.org/ #349763
I am new to python packaging and I'm a little concerned about this
'setup.py'.
It duplicates debian/control. So whilst maintaining one I have to worry
about keeping debian/control
On Thu, 2006-02-02 at 21:09 +0100, Matthias Klose wrote:
> > that is, packages with private modules but without extension modules
> > and no modules in /usr/lib/python2.x. how many packages are this?
2006/2/3, Joe Wreschnig <[EMAIL PROTECTED]>:
> Off the top of my head and in no particular order:
On Thu, 2006-02-02 at 23:02 +0100, Josselin Mouette wrote:
> Le jeudi 02 février 2006 à 21:09 +0100, Matthias Klose a écrit :
> > Josselin Mouette writes:
> > > There is still a situation we can improve easily, though: private
> > > modules. Currently, they have to migrate with python transitions,
Le jeudi 02 février 2006 à 21:09 +0100, Matthias Klose a écrit :
> Josselin Mouette writes:
> > There is still a situation we can improve easily, though: private
> > modules. Currently, they have to migrate with python transitions, and
> > this is only because of byte-compilation. The python-suppor
lib/python2.x. how many packages are this?
Off the top of my head and in no particular order: pydance, solarwolf,
pathological (this is standard practice in the Pygame community), uligo,
linda, pychecker, amarok, reportbug, dput, python-gtk2-dev, straw,
gdesklets-data, hal-device-manager.
My bra
Josselin Mouette writes:
> There is still a situation we can improve easily, though: private
> modules. Currently, they have to migrate with python transitions, and
> this is only because of byte-compilation. The python-support way of
> doing things should still be fine for them, and it can reduce
Le jeudi 26 janvier 2006 à 15:26 +0100, Matthias Klose a écrit :
> While preparing some example packages to experiment with
> python-central and python-support, I did see some issues with both
> proposals, in that the dependencies are not fulfilled for every python
> version that both packaging sys
While preparing some example packages to experiment with
python-central and python-support, I did see some issues with both
proposals, in that the dependencies are not fulfilled for every python
version that both packaging systems claim to support. Feedback is
welcome.
For an example see python-pm
Steve Langasek writes:
> On Fri, Jan 20, 2006 at 10:47:19AM +0100, Matthias Klose wrote:
> > Steve Langasek writes:
> > > On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote:
>
> > > > the design decision of putting the binary-all python packages in a
> > > > separate directory into /va
On Fri, Jan 20, 2006 at 10:47:19AM +0100, Matthias Klose wrote:
> Steve Langasek writes:
> > On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote:
> > > the design decision of putting the binary-all python packages in a
> > > separate directory into /var/lib/python2.x/site-packages has s
Steve Langasek writes:
> On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote:
> > Josselin Mouette writes:
> > > Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit :
> > > > This is the right direction, and adding support for extensions makes
> > > > this complete. Does your
On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote:
> Josselin Mouette writes:
> > Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit :
> > > This is the right direction, and adding support for extensions makes
> > > this complete. Does your proposal allow rebuilding these p
Josselin Mouette writes:
> Le mercredi 18 janvier 2006 à 13:06 +0100, Matthias Klose a écrit :
> As I already explained on IRC, dh_python will not hand .py files to
> python-support in architecture-dependent packages containing a .so
> module. This is unnecessary and would bring issues like this on
Le mercredi 18 janvier 2006 à 13:06 +0100, Matthias Klose a écrit :
> the design decision of putting the binary-all python packages in a
> separate directory into /var/lib/python2.x/site-packages has some
> problems when supporting packages with extensions (a proposal beeing
> made on #irc was to k
Josselin Mouette writes:
> Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit :
> > This is the right direction, and adding support for extensions makes
> > this complete. Does your proposal allow rebuilding these packages
> > without actually changing anything (except the changelog).
>
Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit :
> > Python-support already handles private modules. As for extensions, I
> > don't think we should change the current packaging practise. Packaging
> > them is already complicated enough as it is.
>
> yes, a reason to simplify this.
Josselin Mouette writes:
> > correct, but making it easier for extensions and applications using
> > private modules as well. when will python-support be able to support
> > these?
>
> Python-support already handles private modules. As for extensions, I
> don't think we should change the current p
1 - 100 of 131 matches
Mail list logo
