Re: Policy for naming python packages
>> In my opinion, packages like "pygtk" and "pyqt" that add new >> modules to Python should always be renamed to "python-*" [...] > [...] > As far as finding stuff in dselect goes... try "/". That is what I'm doing. But dselect does only support simple substring searches and when I'm searching for "py" I find packages like "happy" or "floppybackup" which I'm not interested in. > I think it would be much more difficult to find Debianized > packages if they had a different name than what the author > originally gave them, That's only true if you know the upstream package's name. Quite often I want to find out if there's already a module that provides some functionality I need, and then I browse through the descriptions of the packages beginning with "python-".
Re: Policy for naming python packages
On 10 Jun 2000, Andreas Voegele wrote: > >> In my opinion, packages like "pygtk" and "pyqt" that add new > >> modules to Python should always be renamed to "python-*" [...] > > > [...] > > > As far as finding stuff in dselect goes... try "/". > > That is what I'm doing. But dselect does only support simple substring > searches and when I'm searching for "py" I find packages like "happy" > or "floppybackup" which I'm not interested in. Good point. > > I think it would be much more difficult to find Debianized > > packages if they had a different name than what the author > > originally gave them, > > That's only true if you know the upstream package's name. Quite often > I want to find out if there's already a module that provides some > functionality I need, and then I browse through the descriptions of > the packages beginning with "python-". Hmmm, ok. I find that I am usually looking to see if some module mentioned in a doc|message|website has been Debianized, and end up using the form at .../distrib/packages to do a search. I've been kicking around an idea that would both solve this problem and enhance Debian[1]... how about having an index of all Python related packages, everything that depends on python-base. It should be trivial to generate this list automatically (on demand or daily) using the same process that generates the web based package trees; it would probably make more sense to divide the list into Python versions, instead of stable(/frozen)/unstable. The end result would be a python.html page that operated like the web based package trees, the tough bit (?) would be taking it offline. I mentioned something similar to Jay T. awhile back (IIRC, it did appear on debian-www), he didn't think it was worth the effort since the task-python-* packages provided much of the same information; the problem with using the task packages to get at this information is that it would be a major PITA to keep the task packages uptodate for 2 or 3 distributions. later, Bruce [1] - There could be Python, C, C++, Icon, Fortran, PHP?, etc. pages; a good resource for programmers wanting to see what Debian offers, without the error prone hassle of searching through the whole archive when you may not know exactly what you are looking for.
Re: Policy for naming python packages
On Sat, Jun 10, 2000 at 11:56:46AM -0600, Bruce Sass wrote: > On 10 Jun 2000, Andreas Voegele wrote: > > >> In my opinion, packages like "pygtk" and "pyqt" that add new > > >> modules to Python should always be renamed to "python-*" [...] > > > > > [...] > > > > > As far as finding stuff in dselect goes... try "/". > > > > That is what I'm doing. But dselect does only support simple substring > > searches and when I'm searching for "py" I find packages like "happy" > > or "floppybackup" which I'm not interested in. > > Good point. What about RE-searching for ^py ???
Re: Policy for naming python packages
On Fri, Jun 09, 2000 at 02:44:36PM +0200, JИrТme Marant wrote:
> > I am pretty sure that python- prefix is for packages that provide some
> > functionality
> > in /usr/lib/site-python, /usr/lib/python{version}/site-packages
>
> Do you mean those whose .py files directly fit in site-packages itself ?
> There are plenty of libraries that are not prefixed with 'python-' and
> located in /usr/lib/python{version}/site-packages/package-name.
> For instance: HTMLgen, sulfur and many others.
>
> I didn't find any policy about python, except a README.maintainers in
> /usr/share/doc/python.
> If there is is no such policy, I would a very interested in helping
> writing such a document.
Neither me. I do remember there was something about that but I do not remember
what this duscussion resulted in. :)
I'd say that if a package contains a library only, it should be named like
python-, and if it also contains an executable (like HTMLgen does or
linbot) it should be named after its upstream name...
--
Misha
Re: Policy for naming python packages
On Sat, Jun 10, 2000 at 10:38:07PM +0200, Tomasz Wegrzanowski wrote:
>
> What about RE-searching for ^py ???
"grep-available python" is useful as well. To get a list of all the
packages that have "python" in the requirements or descriptions, you
can do "grep-available python|grep ^Package|awk '{print $2}'|wc -l"
(113 packages in woody).
If you don't have "grep-available", it's in the "grep-dctrl" package.
Quite a handy little util.
--
Aaron Malone ([EMAIL PROTECTED])
System Administrator "Of course I'm crazy, but that
Poplar Bluff Internet, Inc.doesn't mean I'm wrong."
http://www.semo.net -- Robert Anton Wilson
Re: Policy for naming python packages
On Sat, Jun 10, 2000 at 10:21:39PM -0500, Aaron Malone wrote:
> can do "grep-available python|grep ^Package|awk '{print $2}'|wc -l"
oops. Lose the "|wc -l" from that, I pasted from a terminal and
forgot to remove it. :)
--
Aaron Malone ([EMAIL PROTECTED])
System Administrator "Of course I'm crazy, but that
Poplar Bluff Internet, Inc.doesn't mean I'm wrong."
http://www.semo.net -- Robert Anton Wilson
