[Catalog-sig] If PyPI is more strict with its packages, may be we can build binary packages from them directly.
"Martin v. Löwis"
martin at v.loewis.de
Mon Oct 6 21:33:17 CEST 2008
> Sure, of course it is a problem of the author. And this policy may help PyPI
> to collect more packages for users. But this fault will defeat the user but not
> the author, why user have to bear the the fault of the author? Now there are
> many packages in PyPI already, may be it is a time to let the author care about
> this problem to make the user more comfortable? :)
I fail to see why this creates a problem for the users.
> In fact, pypi2pkgsys can scan PyPI catalog automatically and log all broken
> packages automatically. There is the log statistics:
> $ sudo pypi-logstats.py /var/tmp/pypi/pypi2pkgsys.log
> /var/tmp/pypi/pypi2pkgsys.log: 2902(59.95%) ok, 0( 0.00%) manual,
> 1939(40.05%) bad.
> The reason of the damage is diversity, may be broken by bad name, may
> be broken by
> unrecognized license (Somebody use GPL, somebody use
> somebody use http://www.opensource.org/licenses/gpl-license.php).
Hmm. Maybe if you also look at the Trove classifiers, your recognition
for licenses is better.
I don't want to restrict package authors in the licenses that they chose
for their software. If they chose a license that is not yet recognized,
your tool certainly won't be able to map it to some well-known list of
licenses (which you apparently need for some reason I don't understand).
However, why should PyPI restrict the licenses for Python packages to
the list of licenses that pyp2pkgsys supports?
> Somebody embedded all of
> the text into license argument of setup...... And the site of many
> packages are not accessable, and
> I can not get any code from them.
And that's intentional. This is the Python Package *Index*, not
a Python package repository. Some people chose to provide source
code, others don't. Perhaps the package isn't even free software.
> As I known, gentoo ebuild require a standardizied format on license.
> I'm not want to apply the rule of
> ebuild to PyPI, but just hope to refine it. As you see, for GPL, there
> are many varieties in PyPI:
> GPL, general public licence, http://www.gnu.org/licenses/gpl.txt,
Hmm. I personally don't think anything should change about that.
More information about the Catalog-SIG