Re: [Distutils] Name the software! Package quality tester.
Who are going to PyCon? I feel an open space on this coming up. :-) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
I really should let this rest ... really On Wed, Mar 9, 2011 at 11:43 AM, P.J. Eby p...@telecommunity.com wrote: At 07:06 AM 3/9/2011 -0500, Jim Fulton wrote: They certainly aren't projects in any sense that most people would understand. I don't follow you. Sourceforge hosts projects. Freshmeat indexes projects. Mozdev.org hosts projects. The Apache Foundation hosts projects. Project, IOW, is *exactly* the word people use for these things, in the larger world of software, and that's precisely why I chose it for my original terminology proposal. But the things in PyPI are not projects. Projects have bug trackers, and mailing lists, and source code repositories. Projects are organizations of people -- not software distributions. The things in PyPI that you call projects are things that get produced by projects. There isn't a buildout.recipe.egg project. buildout.recipe.egg is just a um packaging of some software components. It's not a project in any usual sense of the word. The term project has has never stuck, despite being discussed repeatedly. It's only been discussed here, on this list. It hasn't been put in official documentation, or really blessed by anybody. When it has been discussed, it's been considered a reasonable name, and when people have needed to make the distinction, they've tended to use it. OK, fair enough. Distutils uses the name package for both Python packages and for the things it makes distributions of. The historical precedent from official documentation is to use package for what you call project. Let's stick with that. :) And let's face it, it really only makes a difference if you are creating some kind of packaging or distribution tool, or if you have a corner case of using one. No. End users need to know about this. They need to know what these names mean and that the package name (distutils) or project name (setuptools) doesn't imply that the distribution will provide a python package of the same name. Trust me on this. Users care about this. For one thing, if the distutils documentation simply starts out like: If you want to distribute your work to the larger Python community, you need to create a project for it. In practical terms, this means having a directory with a setup.py and the code, data, or documentation you wish to distribute. Your project will also need a unique name, if you want to make it accessible to others via the Python Project Index (PyPI). (replace setup.py w/setup.cfg for distutils2, of course) It does? Where? Can you give a link? I don't see this text anywhere. This usage of project also maps onto common IDE usage of the term project -- a directory of stuff that you're going to edit and build. That use of project is equivalent to working directory and not relevant, IMO. And, it immediately introduces the term to a superset of the audience that will need to know it. Having PyPI describe its contents as projects is pretty much the other half of the indoctrination needed. Only if you think indoctrination is needed. I'd rather make things more obvious. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
At 08:08 AM 3/10/2011 -0500, Jim Fulton wrote: I really should let this rest ... really I notice you seem to have already let rest defending your proposal, as opposed to opposing mine. ;-) That is, I don't see where you've included any counterargument for why convincing people to *stop* using package for python package isn't going to be a lot harder than simply *adding* the term project to existing docs, via simple explanations like this one: If you would like to distribute your python package or module, you need to create a project. A project consists of a directory containing the package(s) or module(s) you want to distribute, along with a setup.py/.cfg, specifying the project's name, current version number, and other information. If you wish to distribute your package via PyPI, then you must choose a unique project name and register it. If you are only distributing one module or package, you can name the project after it, as long as it doesn't conflict with any other project names already registered on PyPI. Context-specific explanations like this are easy to give, at a place where the recipient of the explanation *wants* to learn something. In contrast, to convince everybody in the world to replace package with module, you must send out a constant broadcast to people who don't really care. (your other points are addressed below) On Wed, Mar 9, 2011 at 11:43 AM, P.J. Eby p...@telecommunity.com wrote: At 07:06 AM 3/9/2011 -0500, Jim Fulton wrote: They certainly aren't projects in any sense that most people would understand. I don't follow you. Sourceforge hosts projects. Freshmeat indexes projects. Mozdev.org hosts projects. The Apache Foundation hosts projects. Project, IOW, is *exactly* the word people use for these things, in the larger world of software, and that's precisely why I chose it for my original terminology proposal. But the things in PyPI are not projects. Projects have bug trackers, and mailing lists, and source code repositories. And which of those things have to be hosted on the same site as the project's index page? Freshmeat, for example, is not a project *hosting* system, it's a project *index*. PyPI is in that sense, a project index. Some index pages may link to all the stuff associated with that project, some may not. (i.e. the set of all possible project features is not equal to the intersection of all projects' actual features: some project have mailing lists and not bug trackers, and vice versa. This does not make them non-projects.) Projects are organizations of people -- not software distributions. I'm an organization of people; am I a project? No, the various things I have listed on PyPI are my projects, and I distribute releases of them. The things in PyPI that you call projects are things that get produced by projects. There isn't a buildout.recipe.egg project. buildout.recipe.egg is just a um packaging of some software components. It's not a project in any usual sense of the word. I don't get that. You work on it, and it is distinct from other works. That makes it a project. No. End users need to know about this. They need to know what these names mean and that the package name (distutils) or project name (setuptools) doesn't imply that the distribution will provide a python package of the same name. Trust me on this. Users care about this. Actually, I believe distutils calls it a distribution name, but I could be wrong about that. ;-) For one thing, if the distutils documentation simply starts out like: If you want to distribute your work to the larger Python community, you need to create a project for it. In practical terms, this means having a directory with a setup.py and the code, data, or documentation you wish to distribute. Your project will also need a unique name, if you want to make it accessible to others via the Python Project Index (PyPI). (replace setup.py w/setup.cfg for distutils2, of course) It does? Where? Can you give a link? I don't see this text anywhere. Of course not; it was a proposal for a hypothetical introduction. That's why it says if up there. ;-) This usage of project also maps onto common IDE usage of the term project -- a directory of stuff that you're going to edit and build. That use of project is equivalent to working directory and not relevant, IMO. Huh? In an IDE, a project is a thing you build and distribute, usually with source control. It's distinct from other projects, and it has a name. It is usually not tied to a specific code unit such as a module or package (regardless of what the code units of the relevant programming language are called). It has additional metadata, over and above the actual code units, and possibly includes non-code resources such as documentation, data, images, etc. IOW, it's *exactly* the sort of project we're talking about here. So, the term project is
Re: [Distutils] Name the software! Package quality tester.
On Tue, Mar 8, 2011 at 6:00 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Jim Fulton wrote: I question whether that distinction is important, but if and when it is, then we could use an adjective to clarify. Under the hood, the object we call packages today are just modules. I think the fact that we used the word package in the first place testifies that it *is* important -- otherwise we wouldn't have invented the term. We invented the term long before distutils was invented and without much, of any, consideration for software distribution. Just because we've historiaclly uses a term, doesn't mean it's a good term. The word package covers much more than just the module object that comes into being when you import it. It also implies the associated directory structure, extra import facilities and mechanisms, etc. It's not just a minor variation on the concept of a module. I agree to disagree. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
On Tue, Mar 8, 2011 at 12:26 PM, P.J. Eby p...@telecommunity.com wrote: At 05:18 PM 3/7/2011 -0500, Jim Fulton wrote: If what we now call packages were called modules, then we could start using the term package the way everyone else does. I think lots of people would be less confused. It seems to me that in order to make that change, you have to get more people to change their terminology, since the set of people who need to refer to package[module] is larger than the set of people who need to refer to package[project]. (There is also a larger body of documentation associated with package[module].) IOW, I think this proposal is a heavy uphill battle, both in the number of people to be convinced and the amount of documentation. In addition, the people who are calling a project a package can more easily understand the need to call it a project, than the people who are calling a package a package, will understand the need to call it a module. ;-) Otherwise, I prefer we try hard to use the precise definitions above. This topic can be confusing enough without making it more so through sloppy terminology. I think that this approach is more achievable: it requires only an official blessing, a relatively small amount of documentation to be changed, and the renaming of PyPI et al. (i.e. Python Projects Index, projects.python.org, etc.) The term project has has never stuck, despite being discussed repeatedly. I think given the historical use of the term package it was reasonable to find another term. OK, we tried. It didn't work. We can pretent that if we work hard enough, we can make people adopt our confusing terminology. Good luck with that. (Projects Index is a better name anyway, since some things on PyPI are not packages at all but applications, scripts, modules, plugins, etc.) They aren't packages a according to current Python definition of the term. They *are* packages according to the common usage within the industry. They certainly aren't projects in any sense that most people would understand. They are arguably products of projects. Of course, the term product has negative connotations for some folks. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
At 07:06 AM 3/9/2011 -0500, Jim Fulton wrote: They certainly aren't projects in any sense that most people would understand. I don't follow you. Sourceforge hosts projects. Freshmeat indexes projects. Mozdev.org hosts projects. The Apache Foundation hosts projects. Project, IOW, is *exactly* the word people use for these things, in the larger world of software, and that's precisely why I chose it for my original terminology proposal. Many PyPI listings also only describe a project, in the sense that there is no release information at all, or the code is only available via a revision control system, etc. The term project has has never stuck, despite being discussed repeatedly. It's only been discussed here, on this list. It hasn't been put in official documentation, or really blessed by anybody. When it has been discussed, it's been considered a reasonable name, and when people have needed to make the distinction, they've tended to use it. The primary reason it hasn't caught on in a larger sense is that people don't know about it, and have no motivation to learn it unless they end up in a situation where the distinction makes a difference... And let's face it, it really only makes a difference if you are creating some kind of packaging or distribution tool, or if you have a corner case of using one. I think given the historical use of the term package it was reasonable to find another term. OK, we tried. It didn't work. I don't think that's an accurate assessment on two points. First, we didn't try -- *I* did. (It's possible that someone else has promoted it, but I don't recall any instances of that.) So, there actually being a we behind it -- where we includes an approved PEP, documentation, etc., would be helpful. Second, I don't think it's accurate to say it didn't work. It's not like people who need the distinction have objected to the word or proposed any alternatives. We can pretent that if we work hard enough, we can make people adopt our confusing terminology. Good luck with that. No matter which way we go (assuming there aren't any other alternatives), we will be trying to get some group of people to change their terminology. I'm just pointing out that the group that would need to change to use project is both smaller *and* inherently more motivated to change their usage, than the group that would need to replace package with module. Thus, if getting people to use project is an uphill battle, getting people to stop using package is going to be a much higher vertical cliff. ;-) For one thing, if the distutils documentation simply starts out like: If you want to distribute your work to the larger Python community, you need to create a project for it. In practical terms, this means having a directory with a setup.py and the code, data, or documentation you wish to distribute. Your project will also need a unique name, if you want to make it accessible to others via the Python Project Index (PyPI). (replace setup.py w/setup.cfg for distutils2, of course) This usage of project also maps onto common IDE usage of the term project -- a directory of stuff that you're going to edit and build. And, it immediately introduces the term to a superset of the audience that will need to know it. Having PyPI describe its contents as projects is pretty much the other half of the indoctrination needed. In contrast, to make the package-module change, you'd have to not only change the official language reference and tutorial, but also every third-party book or tutorial about Python. Sure, some of those third party references would also exist for package as project, but that's simply an *imprecise* usage, rather than an *incorrect* one. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
On Mar 9, 2011, at 7:06 AM, Jim Fulton j...@zope.com wrote: They certainly aren't projects in any sense that most people would understand. They are arguably products of projects. Of course, the term product has negative connotations for some folks. Not for everybody! As far as I am concerned, the whole Python packaging ecosystem (not to mention every Twisted-based plugin mechanism and extension point) is merely trying to re-ascend to the lofty heights once occupied by the beautiful completeness and usability of the zope2 product architecture :). (Not kidding! I loved those things.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
FWIW, when I've been writing docs or answering packaging questions and trying to use the approved, unambiguous terminology, using project for thing with a PyPI page has never been a problem; I've had much more difficulty in using distribution as the term for a zipfile or tarball or egg that you download (also a package in colloquial usage). I always have to awkwardly qualify it with distribution tarball or project distribution due to the conflict with Linux distributions. Carl ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
They certainly aren't projects in any sense that most people would understand. I don't follow you. Maybe we have lost the context here, but I think I agree with Jim. Even though PyPI hosts projects, they (the files you download) aren't projects - they are distributions or packages. Regards, Martin ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
At 10:22 PM 3/9/2011 -0500, Martin v. Löwis wrote: They certainly aren't projects in any sense that most people would understand. I don't follow you. Maybe we have lost the context here, but I think I agree with Jim. Even though PyPI hosts projects, they (the files you download) aren't projects - they are distributions or packages. I think you have lost the context; here, project refers to the thing that you have versions of, which distributions in turn are discrete manifestations of. That is, a project has releases which has distributions. For example, http://pypi.python.org/pypi/Trac is a PyPI page for a project, http://pypi.python.org/pypi/Trac/0.12.2 is the PyPI page for release 0.12.2 of that project, and http://pypi.python.org/packages/source/T/Trac/Trac-0.12.2.tar.gz is one of the distributions available for that release of that project. PyPI allows one to host a project that has neither releases nor distributions, so in that sense it is certainly an index of projects, in much the same way that ASF, SourceForge, MozDev, and others are. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
On Mon, Mar 7, 2011 at 21:47, P.J. Eby p...@telecommunity.com wrote: The term has been in use in setuptools since around 2005, but it hasn't caught on much outside of the small group of people who need to be able to speak precisely about the concept. ;-) Well, I've changed the terminology in pyroma, to hopefully spread it around a bit. //Lennart ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
On Mon, Mar 7, 2011 at 23:18, Jim Fulton j...@zope.com wrote: Given that Python 3 is a reboot, maybe it's time for the Python community to start calling these what ``python`` calls them, modules. Well, given that the term project hasn't gained widespread acceptance, maybe we should adjust the terminology to how people actually use it. That could only happen in Python 3.3, though, and obviously needs to be discussed widely. Is there a language summit this year? //Lennart ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
On Mon, Mar 7, 2011 at 6:57 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Jim Fulton wrote: If what we now call packages were called modules, then we could start using the term package the way everyone else does. But then we would not have a term for a module that corresponds to a directory rather than a single .py file. I question whether that distinction is important, but if and when it is, then we could use an adjective to clarify. Under the hood, the object we call packages today are just modules. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
Le 08/03/2011 09:39, Lennart Regebro a écrit : Well, given that the term project hasn't gained widespread acceptance, maybe we should adjust the terminology to how people actually use it. That could only happen in Python 3.3, though, and obviously needs to be discussed widely. Is there a language summit this year? The sure thing is we have to agree on something different that what we already have: packages for directories containing .py files and packages for things we want to distribute, which should have different names. I'm +1 with the idea of replacing packages by modules, especially because this package thing just add some fuss to the overall comprehension. Why do we need to make a distinctions between python packages and python modules ? Why a package does contains modules rather thatn the other way around? If you have some pointers to the discussion (if any) that leaded to these choices, it could certainly help us to understand the rationale leading to this choice, and make us able to chose the right names. We really need to do something about those names *now*, especially because it's not too late to change names in use in distutils2 (it will probably be more complicated once it will be integrated in the stdlib). Maybe can we even match the rename of PyPI into python project index with the release of distutils2 and the renew of python packaging ? Cheers, Alex ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
At 05:18 PM 3/7/2011 -0500, Jim Fulton wrote: If what we now call packages were called modules, then we could start using the term package the way everyone else does. I think lots of people would be less confused. It seems to me that in order to make that change, you have to get more people to change their terminology, since the set of people who need to refer to package[module] is larger than the set of people who need to refer to package[project]. (There is also a larger body of documentation associated with package[module].) IOW, I think this proposal is a heavy uphill battle, both in the number of people to be convinced and the amount of documentation. In addition, the people who are calling a project a package can more easily understand the need to call it a project, than the people who are calling a package a package, will understand the need to call it a module. ;-) Otherwise, I prefer we try hard to use the precise definitions above. This topic can be confusing enough without making it more so through sloppy terminology. I think that this approach is more achievable: it requires only an official blessing, a relatively small amount of documentation to be changed, and the renaming of PyPI et al. (i.e. Python Projects Index, projects.python.org, etc.) (Projects Index is a better name anyway, since some things on PyPI are not packages at all but applications, scripts, modules, plugins, etc.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
Jim Fulton wrote: I question whether that distinction is important, but if and when it is, then we could use an adjective to clarify. Under the hood, the object we call packages today are just modules. I think the fact that we used the word package in the first place testifies that it *is* important -- otherwise we wouldn't have invented the term. The word package covers much more than just the module object that comes into being when you import it. It also implies the associated directory structure, extra import facilities and mechanisms, etc. It's not just a minor variation on the concept of a module. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
I've started working on a little utility to give a quality rating on packages Please don’t call those things packages. Let’s try to use “package” only for a directory that you can import from Python, and “distribution” for a bundle/archive of one version of a project. http://tarekziade.wordpress.com/2010/01/07/fixing-packaging-terminology-confusion/ http://docs.python.org/dev/distutils/introduction#concepts-terminology Regards ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
On Mon, Mar 7, 2011 at 11:01, Éric Araujo mer...@netwok.org wrote: I've started working on a little utility to give a quality rating on packages Please don’t call those things packages. Let’s try to use “package” only for a directory that you can import from Python, and “distribution” for a bundle/archive of one version of a project. http://tarekziade.wordpress.com/2010/01/07/fixing-packaging-terminology-confusion/ http://docs.python.org/dev/distutils/introduction#concepts-terminology The problem is that it's not distributions (although it will test them too). It's Things that has a setup.py and what has an entry on PyPI. This is generally called a package, as in Python *Package* Index. I agree this is confusing. But saying that Pyroma tests distributions would also be confusing. :-) If a decision comes to call these projects, then I'm fine with that, but currently they are called packages. /Lennart ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
2011/3/7 Éric Araujo mer...@netwok.org: The problem is that it's not distributions (although it will test them too). It's Things that has a setup.py and what has an entry on PyPI. Okay, so that’s called a project in distutils docs In distutils2, yes. My point is that if we have to live with this imperfect situation, we should try to remain consistent as much as possible to prevent confusion I'll make a note of this in the documentation to clear it up. Distutils2 is definitely in the minority at the moment when it comes to calling them projects. //Lennart ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
Okay, so that’s called a project in distutils docs In distutils2, yes. You’re right, I checked again and found that “packages” has slipped into distutils docs, so it’s only the PEPs and distutils2 docs that try to be sane. Thanks for listening to my request. :) Regards ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
On Mon, Mar 7, 2011 at 4:15 PM, P.J. Eby p...@telecommunity.com wrote: At 11:46 AM 3/7/2011 +0100, Lennart Regebro wrote: I'll make a note of this in the documentation to clear it up. Distutils2 is definitely in the minority at the moment when it comes to calling them projects. The term has been in use in setuptools since around 2005, but it hasn't caught on much outside of the small group of people who need to be able to speak precisely about the concept. ;-) If you search the sig archives, though, you will find that it gets proposed and mostly-approved every time the topic comes up, of what to call these things we distribute releases of. The more-or-less consensus terminology (for people who need a precise terminology): package = thing you import in Python that contains modules project = thing you make releases of release = one version of a project distribution = a file that embodies the release of a project (may be source or binary) +1 People who don't care about precision just call everything a package, pretty much. Heck, a lot of times I find myself starting to type package when I'm really talking about a project, release, or distribution, despite promoted the more-precise terminology for half a decade or so. ;-) The root of the problem, IMO, is Python's (mis)use of the name package for what is really only a nested module. Heck: import distutils distutils module 'distutils' ... Given that Python 3 is a reboot, maybe it's time for the Python community to start calling these what ``python`` calls them, modules. If what we now call packages were called modules, then we could start using the term package the way everyone else does. I think lots of people would be less confused. Otherwise, I prefer we try hard to use the precise definitions above. This topic can be confusing enough without making it more so through sloppy terminology. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
Lennart Regebro wrote: If a decision comes to call these projects, then I'm fine with that, +1 on 'project' as the official term. A bonus is that we could decide that PyPI stands for Python Project Index if we wanted. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
On Mar 07, 2011, at 05:18 PM, Jim Fulton wrote: Given that Python 3 is a reboot, maybe it's time for the Python community to start calling these what ``python`` calls them, modules. Very nice. +1. And nested module where the distinction is important. Even namespace module sounds okay to me. -Barry signature.asc Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
Jim Fulton wrote: If what we now call packages were called modules, then we could start using the term package the way everyone else does. But then we would not have a term for a module that corresponds to a directory rather than a single .py file. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Name the software! Package quality tester.
I've started working on a little utility to give a quality rating on packages, expressed in 0-10 points, and also in cheese types, according to smellyness. It's going to check for things like that it has all meta data it should have, such as author_email, specifies Python versions via the trove classifiers (currently works) and that it specifies all dependencies (still todo). It will support both checking on a package (works currently) a distribution file and PyPI (still to do). It's not a uniqe idea, it overlaps with Andreas Jungs zopyx.trashfinder in scope, and it will also in the case of checking a package on PyPI check that there are several people that have owner access, and hence include the functionality of mr.parker. (In fact when checking on PyPI it will also check if there are documentation on packages.python.org, that the distribution files are uploaded to PyPI, etc, but this is all still todo). But I didn't find anything else, and I wanted bigger scopes than both these in what to check in and which cases. But, before I move this to a public repository and upload it to PyPI, there is one important thing to be determined: What should it be called? Currently I'm calling it pypilib.quality. I don't mind this kind of boring names, but there is currently not a pypilib namespace, and I don't want to just create top level namespaces left and right for no reason. So other names are welcome. It doesn't have to have a namespace either. In the long run I would not mind to see this utility integrated into a general pypi/cheeseshop script with other utility commands, which even could include installing and removing, thusly giving Perl people what they think they want a CPAN for Python. :-) -- Lennart Regebro: http://regebro.wordpress.com/ The Python 3 Porting book is out: http://python3porting.com/ +33 661 58 14 64 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
On Mar 6, 2011 3:47 AM, Lennart Regebro rege...@gmail.com wrote: I've started working on a little utility to give a quality rating on packages, expressed in 0-10 points, and also in cheese types, according to smellyness. How about cheese inspecter? -- Benji York ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
On Sun, Mar 6, 2011 at 2:38 PM, Benji York be...@benjiyork.com wrote: On Mar 6, 2011 3:47 AM, Lennart Regebro rege...@gmail.com wrote: I've started working on a little utility to give a quality rating on packages, expressed in 0-10 points, and also in cheese types, according to smellyness. How about cheese inspecter? More ideas: cheeseshop.critic pypi.stickler ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
On Sun, Mar 6, 2011 at 9:46 AM, Lennart Regebro rege...@gmail.com wrote: I've started working on a little utility to give a quality rating on packages, expressed in 0-10 points, and also in cheese types, according to smellyness. It's going to check for things like that it has all meta data it should have, such as author_email, specifies Python versions via the trove classifiers (currently works) and that it specifies all dependencies (still todo). It will support both checking on a package (works currently) a distribution file and PyPI (still to do). It's not a uniqe idea, it overlaps with Andreas Jungs zopyx.trashfinder in scope, and it will also in the case of checking a package on PyPI check that there are several people that have owner access, and hence include the functionality of mr.parker. (In fact when checking on PyPI it will also check if there are documentation on packages.python.org, that the distribution files are uploaded to PyPI, etc, but this is all still todo). But I didn't find anything else, and I wanted bigger scopes than both these in what to check in and which cases. Reminds me a bit about CheeseCake http://pycheesecake.org/ But, before I move this to a public repository and upload it to PyPI, there is one important thing to be determined: What should it be called? Currently I'm calling it pypilib.quality. I don't mind this kind of boring names, but there is currently not a pypilib namespace, and I don't want to just create top level namespaces left and right for no reason. So other names are welcome. It doesn't have to have a namespace either. Camembert ? :D In the long run I would not mind to see this utility integrated into a general pypi/cheeseshop script with other utility commands, which even could include installing and removing, thusly giving Perl people what they think they want a CPAN for Python. :-) -- Lennart Regebro: http://regebro.wordpress.com/ The Python 3 Porting book is out: http://python3porting.com/ +33 661 58 14 64 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig -- Tarek Ziadé | http://ziade.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
On Sun, Mar 6, 2011 at 17:00, Tarek Ziadé ziade.ta...@gmail.com wrote: Reminds me a bit about CheeseCake http://pycheesecake.org/ Indeed, it's a lot like CheeseCake, which I had forgot about and didn't find either by google, pypi or asking on #plone and #python. :-) However, there are a significant difference. CheeseCake is focusing a lot on code quality, while I'm only interested in how well it plays with the pypi ecosystem. The percentage of functions with docstrings seems to me to be highly irrelevant, as well. That's more like the percentage of public vs private functions, and not a measure of quality at all. So CheeseCake can take care of code quality, and this will do package quality. :-) //Lennart ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
Excellent idea Lennart... On Mar 06, 2011, at 03:51 PM, Brad Allen wrote: cheeseshop.critic pypi.stickler I like the cheeseshop namespace used for this. Or maybe wenslydale :) http://orangecow.org/pythonet/sketches/cheese.htm -Barry signature.asc Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
The winner is Wichert, with pyroma. I do like the stickler name, and the cheeseshop namespace, but since there is nothing else in that namespace I'll wait with it. It can easily be moved to a cheeseshop.compliance or whatever in the future, but that the moment it's pyroma. I'll check it in somewhere soon, maybe work a bit more on the plane to PyCon and probably mention it in a lightning talk. //Lennart On Sun, Mar 6, 2011 at 09:46, Lennart Regebro rege...@gmail.com wrote: I've started working on a little utility to give a quality rating on packages, expressed in 0-10 points, and also in cheese types, according to smellyness. It's going to check for things like that it has all meta data it should have, such as author_email, specifies Python versions via the trove classifiers (currently works) and that it specifies all dependencies (still todo). It will support both checking on a package (works currently) a distribution file and PyPI (still to do). It's not a uniqe idea, it overlaps with Andreas Jungs zopyx.trashfinder in scope, and it will also in the case of checking a package on PyPI check that there are several people that have owner access, and hence include the functionality of mr.parker. (In fact when checking on PyPI it will also check if there are documentation on packages.python.org, that the distribution files are uploaded to PyPI, etc, but this is all still todo). But I didn't find anything else, and I wanted bigger scopes than both these in what to check in and which cases. But, before I move this to a public repository and upload it to PyPI, there is one important thing to be determined: What should it be called? Currently I'm calling it pypilib.quality. I don't mind this kind of boring names, but there is currently not a pypilib namespace, and I don't want to just create top level namespaces left and right for no reason. So other names are welcome. It doesn't have to have a namespace either. In the long run I would not mind to see this utility integrated into a general pypi/cheeseshop script with other utility commands, which even could include installing and removing, thusly giving Perl people what they think they want a CPAN for Python. :-) -- Lennart Regebro: http://regebro.wordpress.com/ The Python 3 Porting book is out: http://python3porting.com/ +33 661 58 14 64 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
Speaking of names, I would rename PyPI to packages.python.org, maybe move the existing documentation center to docs.python.org, and then move the docs of Python itself to a `/python` folder... But that's just me. On Sun, Mar 6, 2011 at 9:40 PM, Lennart Regebro rege...@gmail.com wrote: The winner is Wichert, with pyroma. I do like the stickler name, and the cheeseshop namespace, but since there is nothing else in that namespace I'll wait with it. It can easily be moved to a cheeseshop.compliance or whatever in the future, but that the moment it's pyroma. I'll check it in somewhere soon, maybe work a bit more on the plane to PyCon and probably mention it in a lightning talk. //Lennart On Sun, Mar 6, 2011 at 09:46, Lennart Regebro rege...@gmail.com wrote: I've started working on a little utility to give a quality rating on packages, expressed in 0-10 points, and also in cheese types, according to smellyness. It's going to check for things like that it has all meta data it should have, such as author_email, specifies Python versions via the trove classifiers (currently works) and that it specifies all dependencies (still todo). It will support both checking on a package (works currently) a distribution file and PyPI (still to do). It's not a uniqe idea, it overlaps with Andreas Jungs zopyx.trashfinder in scope, and it will also in the case of checking a package on PyPI check that there are several people that have owner access, and hence include the functionality of mr.parker. (In fact when checking on PyPI it will also check if there are documentation on packages.python.org, that the distribution files are uploaded to PyPI, etc, but this is all still todo). But I didn't find anything else, and I wanted bigger scopes than both these in what to check in and which cases. But, before I move this to a public repository and upload it to PyPI, there is one important thing to be determined: What should it be called? Currently I'm calling it pypilib.quality. I don't mind this kind of boring names, but there is currently not a pypilib namespace, and I don't want to just create top level namespaces left and right for no reason. So other names are welcome. It doesn't have to have a namespace either. In the long run I would not mind to see this utility integrated into a general pypi/cheeseshop script with other utility commands, which even could include installing and removing, thusly giving Perl people what they think they want a CPAN for Python. :-) -- Lennart Regebro: http://regebro.wordpress.com/ The Python 3 Porting book is out: http://python3porting.com/ +33 661 58 14 64 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig -- Sincerely, Ram Rachum ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
Lennart Regebro wrote: But, before I move this to a public repository and upload it to PyPI, there is one important thing to be determined: What should it be called? Inspector Tiger? http://www.youtube.com/watch?v=UDdCghQYvDY -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
Since mercurial makes me annoyed I decided to use it. I'll have to learn it someday anyway, so why not now? https://bitbucket.org/regebro/pyroma Helpers welcome (although you'll probably have to wait to after PyCon). //Lennart On Sun, Mar 6, 2011 at 20:40, Lennart Regebro rege...@gmail.com wrote: The winner is Wichert, with pyroma. I do like the stickler name, and the cheeseshop namespace, but since there is nothing else in that namespace I'll wait with it. It can easily be moved to a cheeseshop.compliance or whatever in the future, but that the moment it's pyroma. I'll check it in somewhere soon, maybe work a bit more on the plane to PyCon and probably mention it in a lightning talk. //Lennart On Sun, Mar 6, 2011 at 09:46, Lennart Regebro rege...@gmail.com wrote: I've started working on a little utility to give a quality rating on packages, expressed in 0-10 points, and also in cheese types, according to smellyness. It's going to check for things like that it has all meta data it should have, such as author_email, specifies Python versions via the trove classifiers (currently works) and that it specifies all dependencies (still todo). It will support both checking on a package (works currently) a distribution file and PyPI (still to do). It's not a uniqe idea, it overlaps with Andreas Jungs zopyx.trashfinder in scope, and it will also in the case of checking a package on PyPI check that there are several people that have owner access, and hence include the functionality of mr.parker. (In fact when checking on PyPI it will also check if there are documentation on packages.python.org, that the distribution files are uploaded to PyPI, etc, but this is all still todo). But I didn't find anything else, and I wanted bigger scopes than both these in what to check in and which cases. But, before I move this to a public repository and upload it to PyPI, there is one important thing to be determined: What should it be called? Currently I'm calling it pypilib.quality. I don't mind this kind of boring names, but there is currently not a pypilib namespace, and I don't want to just create top level namespaces left and right for no reason. So other names are welcome. It doesn't have to have a namespace either. In the long run I would not mind to see this utility integrated into a general pypi/cheeseshop script with other utility commands, which even could include installing and removing, thusly giving Perl people what they think they want a CPAN for Python. :-) -- Lennart Regebro: http://regebro.wordpress.com/ The Python 3 Porting book is out: http://python3porting.com/ +33 661 58 14 64 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
