Thomas Goirand wrote:
> On 07/11/2013 09:07 PM, Stuart Prescott wrote:
>>
>>> Oh, I need this pyX package... Let's download it.
>>
>> You're using a python module name because you need to import it. If you
>> want to import modules, you want the binary package name; if you want to
>> work on the
On Fri, Jul 12, 2013 at 12:22 AM, Thomas Goirand wrote:
> I've seen both cases in the archive!
DEP-11 FTW.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debia
On 07/11/2013 09:07 PM, Stuart Prescott wrote:
>
>> Oh, I need this pyX package... Let's download it.
>
> You're using a python module name because you need to import it. If you want
> to import modules, you want the binary package name; if you want to work on
> the source package then you need
> Oh, I need this pyX package... Let's download it.
You're using a python module name because you need to import it. If you want
to import modules, you want the binary package name; if you want to work on
the source package then you need *either* the binary package name or the
source package n
On 07/11/2013 04:07 AM, Piotr Ożarowski wrote:
> [Thomas Goirand, 2013-07-10]
>> And then, finally, it's called "migrate" instead of "sqlalchemy-migrate"
>> like upstream called it... :)
>> (this never happened to me with python-migrate, though that's a good
>> example of a IMO badly named source p
On 07/11/2013 03:59 AM, Bradley M. Froehle wrote:
> I think a recommendation (for new packages) would be helpful, but I'm
> against any source naming requirements or strict rules.
Then we agree! That's all what I'm asking for.
Thomas
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debi
On Thu, Jul 11, 2013 at 3:54 AM, Thomas Goirand wrote:
> Oh, I need this pyX package... Let's download it.
I assume here you mean "I need whatever package provides 'import pyX'
for python"? If so this is solvable using something like DEP-11 that
maps package names to things that they provide (sha
On Jul 11, 2013, at 03:54 AM, Thomas Goirand wrote:
>Ok, so let's not use the word "rule" but call it "guide-line", and for
>future packages only (I have *never* proposed to change already uploaded
>packages). Do you feel more comfortable now? :)
Does your response mean you disagree with my sugge
[Thomas Goirand, 2013-07-10]
> And then, finally, it's called "migrate" instead of "sqlalchemy-migrate"
> like upstream called it... :)
> (this never happened to me with python-migrate, though that's a good
> example of a IMO badly named source package)
if you wanted to download python-migrate's s
On Wed, Jul 10, 2013 at 12:54 PM, Thomas Goirand wrote:
> On 07/10/2013 10:30 PM, Stuart Prescott wrote:
>> Thomas Goirand wrote:
>>> On 07/08/2013 10:10 PM, Scott Kitterman wrote:
There is no policy on this either way, so there's no "mistake".
>>>
>>> Well, the mistake is precisely to have n
On 07/10/2013 10:30 PM, Stuart Prescott wrote:
> Thomas Goirand wrote:
>> On 07/08/2013 10:10 PM, Scott Kitterman wrote:
>>> There is no policy on this either way, so there's no "mistake".
>>
>> Well, the mistake is precisely to have no rule, IMO.
>
> Rules for packaging things are normally there
Am 10.07.2013 16:30, schrieb Stuart Prescott:
> Thomas Goirand wrote:
>> On 07/08/2013 10:10 PM, Scott Kitterman wrote:
>>> There is no policy on this either way, so there's no "mistake".
>>
>> Well, the mistake is precisely to have no rule, IMO.
>
> Rules for packaging things are normally there t
[Stuart Prescott, 2013-07-10]
> What mess? If there is a perceived mess, why is that a problem in any case?
> How does it help to make a new rule? Who does it help? What problem does
> this solve? Why is any intellectual energy being spent on this at all?
>
> It looks exceedingly like a rule for
On Thursday, July 11, 2013 12:30:54 AM Stuart Prescott wrote:
> Thomas Goirand wrote:
> > On 07/08/2013 10:10 PM, Scott Kitterman wrote:
> >> There is no policy on this either way, so there's no "mistake".
> >
> > Well, the mistake is precisely to have no rule, IMO.
>
> Rules for packaging things
Thomas Goirand wrote:
> On 07/08/2013 10:10 PM, Scott Kitterman wrote:
>> There is no policy on this either way, so there's no "mistake".
>
> Well, the mistake is precisely to have no rule, IMO.
Rules for packaging things are normally there to solve problems of
interoperability and to assist QA
On Jul 10, 2013, at 08:11 AM, Alastair McKinstry wrote:
>FWIW, I think the current scheme works best.
>
>I manage a bunch of packages that have python wrappers; the package
>then pretty much _has_ to follow the current scheme, eg.
>
>Source package: silo
>Bin packages: libsilo0
>
On Jul 10, 2013, at 02:58 PM, Thomas Goirand wrote:
>On 07/08/2013 10:10 PM, Scott Kitterman wrote:
>> There is no policy on this either way, so there's no "mistake".
>
>Well, the mistake is precisely to have no rule, IMO.
>
>On 07/08/2013 11:37 PM, Barry Warsaw wrote:
>> Hopefully, it will become
FWIW, I think the current scheme works best.
I manage a bunch of packages that have python wrappers; the package
then pretty much _has_ to follow the current scheme, eg.
Source package: silo
Bin packages: libsilo0
libsilo-dev
python-silo
On Wed, Jul 10, 2013 at 8:58 AM, Thomas Goirand wrote:
> On 07/08/2013 10:10 PM, Scott Kitterman wrote:
>> There is no policy on this either way, so there's no "mistake".
>
> Well, the mistake is precisely to have no rule, IMO.
Agreed.
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.de
On 07/08/2013 10:10 PM, Scott Kitterman wrote:
> There is no policy on this either way, so there's no "mistake".
Well, the mistake is precisely to have no rule, IMO.
On 07/08/2013 11:37 PM, Barry Warsaw wrote:
> Hopefully, it will become more and more common to have at least
> python-X and python
Another rule of thumb I use is that if a project is not just about python
module but also provides some GUI or CUI interface which might be used by users
without realizing presence of a python behind I do not prefix with python-, eg
psychopy.
Sandro Tosi wrote:
>On Mon, Jul 8, 2013 at 4:10 PM
On Mon, Jul 8, 2013 at 4:10 PM, Scott Kitterman wrote:
> There is no policy on this either way, so there's no "mistake". Personally, I
> tend to use the upstream name for the source package name and
> python-$modulename (per Python policy) for the binary.
I'm using the same same rule, with just
On Jul 08, 2013, at 09:59 PM, Thomas Goirand wrote:
>Over the last months, I've seen lots of inconsistency in the source
>package naming scheme in the python module maintained in the team.
>Sometimes, module X will have its source package called python-X or just X.
>
>If we have a python module na
Quoting Thomas Goirand (2013-07-08 15:59:02)
> Hi,
>
> Over the last months, I've seen lots of inconsistency in the source
> package naming scheme in the python module maintained in the team.
> Sometimes, module X will have its source package called python-X or just X.
>
> If we have a python mod
On Monday, July 08, 2013 09:59:02 PM Thomas Goirand wrote:
> Hi,
>
> Over the last months, I've seen lots of inconsistency in the source
> package naming scheme in the python module maintained in the team.
> Sometimes, module X will have its source package called python-X or just X.
>
> If we hav
Hi,
Over the last months, I've seen lots of inconsistency in the source
package naming scheme in the python module maintained in the team.
Sometimes, module X will have its source package called python-X or just X.
If we have a python module named X, then IMO, we should stick to call
the source p
26 matches
Mail list logo
