Re: Language extensions in programs under /usr/bin

2003-10-08 Thread Cameron Patrick
On Wed, Oct 08, 2003 at 09:57:42AM +0100, Colin Watson wrote: | > That'd be /usr/share (lib is for arch-dependant data, see FHS) | | ... except that the Python policy seems to have bizarre rules about | this. I assume this is because .pyc files are placed in the same | directory as the correspondi

Re: Language extensions in programs under /usr/bin

2003-10-08 Thread Colin Watson
On Wed, Oct 08, 2003 at 12:19:58AM +, Robert Millan wrote: > On Tue, Oct 07, 2003 at 06:07:58PM -0400, Marco Paganini wrote: > > Yes. "ask.py" is just the main executable. It imports all the other modules > > (which have the .py extension and should be in /usr/lib/ask or something). > > That'd

Re: Language extensions in programs under /usr/bin

2003-10-08 Thread Robert Millan
On Tue, Oct 07, 2003 at 06:37:31PM -0400, Daniel Burrows wrote: > On Tue, Oct 07, 2003 at 06:07:58PM -0400, Marco Paganini <[EMAIL PROTECTED]> > was heard to say: > > On Tue, Oct 07, 2003 at 05:57:42PM -0400, Daniel Burrows wrote: > > > > > > That would not be a problem, as no other program impor

Re: Language extensions in programs under /usr/bin

2003-10-08 Thread Robert Millan
On Tue, Oct 07, 2003 at 06:07:58PM -0400, Marco Paganini wrote: > On Tue, Oct 07, 2003 at 05:57:42PM -0400, Daniel Burrows wrote: > > > > That would not be a problem, as no other program imports ask.py... > > > > Are you confident that no other program will ever want to "import ask"? > > Yes.

Re: Language extensions in programs under /usr/bin

2003-10-07 Thread Daniel Burrows
On Tue, Oct 07, 2003 at 06:07:58PM -0400, Marco Paganini <[EMAIL PROTECTED]> was heard to say: > On Tue, Oct 07, 2003 at 05:57:42PM -0400, Daniel Burrows wrote: > > > > That would not be a problem, as no other program imports ask.py... > > > > Are you confident that no other program will ever

Re: Language extensions in programs under /usr/bin

2003-10-07 Thread Marco Paganini
Hi, > > Yes. "ask.py" is just the main executable. It imports all the other modules > > (which have the .py extension and should be in /usr/lib/ask or something). > > That'd be /usr/share (lib is for arch-dependant data, see FHS) Oops, sorry! Slippery fingers. I meant /usr/share... Regards, Pag

Re: Language extensions in programs under /usr/bin

2003-10-07 Thread Daniel Burrows
On Tue, Oct 07, 2003 at 05:48:17PM -0400, Marco Paganini <[EMAIL PROTECTED]> was heard to say: > Hi Daniel, > > > I think it's worth pointing out that if a file called "ask.py" is in > > /usr/bin, the statement: > > > > import ask > > > > from a Python program in /usr/bin which hasn't modif

Re: Language extensions in programs under /usr/bin

2003-10-07 Thread Marco Paganini
On Tue, Oct 07, 2003 at 05:57:42PM -0400, Daniel Burrows wrote: > > That would not be a problem, as no other program imports ask.py... > > Are you confident that no other program will ever want to "import ask"? Yes. "ask.py" is just the main executable. It imports all the other modules (which

Re: Language extensions in programs under /usr/bin

2003-10-07 Thread Marco Paganini
Hi Daniel, > I think it's worth pointing out that if a file called "ask.py" is in > /usr/bin, the statement: > > import ask > > from a Python program in /usr/bin which hasn't modified its sys.path > will, unless I am terribly confused, pick up ask.py instead of whatever > module it was looki

Re: Language extensions in programs under /usr/bin

2003-10-07 Thread Marco Paganini
Hi Marcello, > > Euh, I think you messed up. Marco *is* upstream. > > That doesn't preclude whackig upstream with a cluebat :-) Here, he can > use mine. I tried whacking myself repeatedly with the cluebat. Unfortunately, it was not as effective as whacking someone else. But I think I got th

Re: Language extensions in programs under /usr/bin

2003-10-07 Thread Bill Allombert
Marco Paganini wrote: > I'm packaging a Python program called "ask" for distribution. Currently, > the main executable is called "ask.py". It seems unusual (and why not say, > *ugly*) to have the language extension added to the program, but in this > case, it was a deliberate decision to avoid

Re: Language extensions in programs under /usr/bin

2003-10-07 Thread Daniel Burrows
On Mon, Oct 06, 2003 at 08:26:44PM -0400, Marco Paganini <[EMAIL PROTECTED]> was heard to say: > I'm packaging a Python program called "ask" for distribution. Currently, > the main executable is called "ask.py". It seems unusual (and why not say, > *ugly*) to have the language extension added to t

Re: Language extensions in programs under /usr/bin

2003-10-07 Thread Marcelo E. Magallon
> > a. Whack upstream with a cluebat. > > Euh, I think you messed up. Marco *is* upstream. That doesn't preclude whackig upstream with a cluebat :-) Here, he can use mine. -- Marcelo

Re: Language extensions in programs under /usr/bin

2003-10-07 Thread John Hasler
Chris writes: > $ ls /usr/bin/*openoffice* > /usr/bin/openoffice > What is dumb about that? The thread is about naming of files within > /usr/bin. Since the package is named openoffice.org supposedly for trademark reasons I assumed that the binary was as well. -- John Hasler [EMAIL PROTECTED] (

Re: Language extensions in programs under /usr/bin

2003-10-07 Thread Matthew Palmer
On Tue, Oct 07, 2003 at 01:24:37PM +, Robert Millan wrote: > > > I'm packaging a Python program called "ask" for distribution. > > > Currently, the main executable is called "ask.py". > > > > a. Whack upstream with a cluebat. > > Euh, I think you messed up. Marco *is* upstream. > > So perh

Re: Language extensions in programs under /usr/bin

2003-10-07 Thread Robert Millan
> > I'm packaging a Python program called "ask" for distribution. > > Currently, the main executable is called "ask.py". > > a. Whack upstream with a cluebat. Euh, I think you messed up. Marco *is* upstream. On the other hand, Marco being upstream defeats John's argument: > Leave it. The pro

Re: Language extensions in programs under /usr/bin

2003-10-07 Thread Chris Halls
On Mon, Oct 06, 2003 at 07:50:07PM -0500, John Hasler wrote: > Besides, if dumb names were a problem we'd do something about > openoffice.org. $ ls /usr/bin/*openoffice* /usr/bin/openoffice What is dumb about that? The thread is about naming of files within /usr/bin. Chris pgpsBIj7fhkCn.pgp D

Re: Language extensions in programs under /usr/bin

2003-10-07 Thread Marcelo E. Magallon
On Mon, Oct 06, 2003 at 08:26:44PM -0400, Marco Paganini wrote: > I'm packaging a Python program called "ask" for distribution. > Currently, the main executable is called "ask.py". a. Whack upstream with a cluebat. b. Repeat a. c. What happens when the program gets reimplemented in another

Re: Language extensions in programs under /usr/bin

2003-10-06 Thread Marco Paganini
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, so far, it's "keep the extension", which is good as it won't break existing installations and create confusion... Thanks, Paga On Mon, Oct 06, 2003 at 05:55:48PM -0700, Steve C. Lamb wrote: > On Mon, Oct 06, 2003 at 07:50:07PM -0500, John Hasle

Re: Language extensions in programs under /usr/bin

2003-10-06 Thread Steve C. Lamb
On Mon, Oct 06, 2003 at 07:50:07PM -0500, John Hasler wrote: > Besides, if dumb names were a problem we'd do something about > openoffice.org. Besides, for people who work with Python they often see the .py extension and don't consider it any more dumb than, say, .pl, .sh, .rb(?) and others.

Re: Language extensions in programs under /usr/bin

2003-10-06 Thread John Hasler
Paga writes: > What would be the best approach, to leave the program as "ask.py" > (unusual) or rename it to "ask" (possibility of name conflicts and > breakage of existing installations)? Leave it. The program will be known as "ask.py" everywhere outside Debian. Changing the name is asking for

Language extensions in programs under /usr/bin

2003-10-06 Thread Marco Paganini
Hi all, I'm packaging a Python program called "ask" for distribution. Currently, the main executable is called "ask.py". It seems unusual (and why not say, *ugly*) to have the language extension added to the program, but in this case, it was a deliberate decision to avoid clash with any other prog