text_combined: phillip j eby moetelecommunitycom 1048 3192008 0700 guido van rossum wrote dont understand pypi well seems poor design browsing via keywords emphasized easy way search keyword list packages emphasized enough main page occurs side bar main text assume theres programmatic api xmlrpc havent found yet httpwikipythonorgmoincheeseshopxmlrpc theres also rest api setuptools uses httppeaktelecommunitycomdevcentereasyinstallpackageindexapi api originally designed screenscraping older version pypi replaced lite version served httppypipythonorgsimple lite version intended tools easy_install process consists strictly links statically cached zope corp example maintains static mirror api guard pypi outages slowdowns since buildouts involve huge numbers eggs external dependencies id love could write point code takes package name optional version returns url source archive type case cant guessed filename contenttype header probably xmlrpc api theres function get versions package given casesensitive name theres function get information uploaded archives given name version originally intended use pep 365 approach get necessary information one static roundtrip using rest simple html api youre willing parse urls version information catch course distutils source distributions dont unambiguously parseable filenames hm use existing convention running setuppy unpacking works great experience advantage easy fallback end manually whatever reason want bootstrapees able use bootstrap mechanism example expect point setuptools use nonselfcontained packages package managers zcbuildout et al also want depend setuptools without bundling calling bootstrap module bootstrap python bootstrap projectname optionalversion module would expose api allow used programmatically well command line bootstrapped packages use bootstrap process locate dependencies desire todays package management tools least based setuptools present theyll need download beginning bootstrapping process sounds like going beyond bootstrapping vision use bootstrap module command line suggest install setuptools alternate package manager choice use easy_install whatever alternative install rest well noticed package managers writing bootstrap scripts download setuptools bootstrap script run part bootstrap process got thinking sure would nice setuptools giant monolithic download wanted start using packages sure would nice get rid bootstrap scripts downloading bootstrap scripts wrote pep 365 one thing pep 365 use cases approach doesnt pkg_resources could detect whether desired package usable version already installed skip weve already scaled back intended use cases quite bit people write already right version checks without one bootstrap tool would grow version parsing scheme type play guessing games file extensions one reason limited pep 365s scope downloading eggs actually uploaded pypi rather arbitrary packages linked pypi two version parsers distutils referenced pep 345 pypi 12 metadata standard yes strictversion doesnt parse release candidates neither looseversion strictversion supports handling multiple prepostrelease tags correctly eg 11a1devr2753 propose something right would inclined propose using setuptools version parsing semantics interpretation alphabetadevetc releases point code advantage distutilsversion implements version comparison semantics closer programmer expectations also far widely used exposed feedback distutilsversion far know really used pep 345 metadata standard isnt used automated tools far know im sure many packages bother declaring addition alphabetacandidatedev versions also supports postrelease patchlevel tags svn revision datebased tags code docstring actually longer bits anything def parse_versions convert version string chronologicallysortable key rough cross distutils strictversion looseversion give versions would work strictversion behaves otherwise acts like slightlysmarter looseversion possible create pathological version coding schemes fool parser rare practice returned value tuple strings numeric portions version padded 8 digits compare numerically without relying numbers compare relative strings dots dropped dashes retained trailing zeros alpha segments dashes suppressed eg 240 considered 24 alphanumeric parts lowercased algorithm assumes strings like alpha string alphabetically follows final represents patch level 241 assumed branch patch 24 therefore 241 considered newer 241 turn newer 24 strings like b c alpha beta candidate come final alphabetically assumed prerelease versions version 24 considered newer 24a1 finally handle miscellaneous cases strings pre preview rc treated c ie though release candidates therefore new version string contain dev replaced sorts lower prerelease tag parts part _parse_version_partsslower partstartswith partfinal remove prerelease tag parts parts1final partspop remove trailing zeros series numeric parts parts parts100000000 partspop partsappendpart return tupleparts component_re recompilerd az reverbose replace prec previewcfinalrccdevget def _parse_version_partss part component_resplits part replacepartpart part part continue part1 0123456789 yield partzfill8 pad numeric comparison else yield part yield final ensure alphabetacandidate final check parse_version value stability loop looking part foo foo desired minimum stability find dont want alphas versions good lets also distinguish beta might accept indevelopment snapshot beta wouldnt whats wrong running setuppy install id rather continue existing standards conventions course wont work setuppy requires setuptools actually setup script uses current ez_setup bootstrapping method setuptools however id like get rid bootstrapping method replace one thats id prefer bootstrap approach use different entry point launching want module expose api dont really want bootstrapper actually install anything one thing means dealing installation options prototype doesnt pass commandline options script people would use pydistutilscfg file order control installation options example break packager included setupcfg supposed overridden command line probably seems lot messy ive face directly planted mess number years know example people bitched moaned excessively able use prefix easy_install way could setuppy install maybe experiences arent relevant im good turning skepticism setuppybased approach close new scheme removing gil level ive gone lot pain get easy_install stage looked lot like bootstrap prototype something actually works time arbitrary distutils packages unfortunately hurdles require release cycles show hey youre okay cool think soon gets field people use far outside anything expect used theres bright line packager cross think well people unhappy tool special step make something bootstrappable tool doesnt work user ask packager take special step however tool allows user point package randomly users pov fails tool python blamed failure even though bootstrap tool package manager close enough look like simpler easy_install people try use one blog bootstrap broken support installation options etc suppose point easy_install something counterexample worry people give packagers patches make setup scripts compatible easy_install cases package extensive distutils modification otoh easy_install de facto standard bootstrap de jure mean practice heck know guess people hate instead maybe view improvement also makes easier understand reluctance way associated eggs theres big difference eggs easy_install imo approach leans towards relative vices easy_install relative virtues eggs oh well _______________________________________________ pythondev mailing list zvlllneumpythonorg httpmailpythonorgmailmanlistinfopythondev unsubscribe httpmailpythonorgmailmanoptionspythondevpythondev40tangomucom wed 06 aug 2008 112828 0400 pythondev pep 365 adding pkg_resources module