Open eGov — City of Newport News
Originally from del.icio.us/tag/plone by
Open eGov — City of Newport News
Originally from del.icio.us/tag/plone by kehorak
a flexible framework for payment processing and commerce in Plone
GetPaid with Plone — Plone CMS: Open Source Content Management
Originally from del.icio.us/tag/plone by miziodel
I decided to create a wiki page about zope 3’s most useful libraries, so I began to look into how to find out which ones are the most popular. Since the Zope 3 community encourages registration of libraries on the Python Package Index, that’s where I began my search.
One quantitative way to define ‘popular’ is by measuring the number of downloads of a library. Presumably, popular libraries will be downloaded more often. The PyPI keeps track of downloads, so I thought that could be good enough to start my list.
Well, the PyPI has an XML-RPC API, but the number of downloads is not available in search results (or at least is not documented). To further complicate matters, package owners can hide old releases, which also will not show in the results. That is a problem, because when you release a new version of a package and hide all the old ones, the download page for the new release will show zero downloads, with no way of knowing which other releases have been made.
The first problem can be easily solved by doing a little screen-scraping; the second problem is harder to solve (I really didn’t try), and basically means that any results I get by using the API have a huge question mark attached.
For my purposes though, the inexact results can be tolerated, since I’m only looking for some of Zope 3 most popular libraries for a documentation page, I’m not trying to create any kind of definitive list.
Anyway, I wrote a quick script and decided to test it first using the whole catalog, so without further ado, here’s the list of PyPI’s 50 greatest hits:
| 34261 | zc.buildout |
| 28431 | simplejson |
| 22887 | FormEncode |
| 20852 | Pylons |
| 18509 | lxml |
| 16160 | ConfigObj |
| 14835 | Routes |
| 12770 | MyghtyUtils |
| 11279 | Myghty |
| 10147 | zope.interface |
| 9994 | PasteDeploy |
| 8539 | TurboCheetah |
| 8456 | setuptools |
| 8455 | zc.recipe.egg |
| 6839 | zope.testing |
| 6352 | kid |
| 5937 | Cheetah |
| 5614 | Mako |
| 5584 | TurboJson |
| 5435 | DecoratorTools |
| 5405 | roundup |
| 5327 | fpconst |
| 5315 | 4Suite-XML |
| 5214 | altgraph |
| 4757 | modulegraph |
| 4591 | macholib |
| 4309 | SQLObject |
| 3908 | zc.recipe.testrunner |
| 3821 | SQLAlchemy |
| 3793 | wsgiref |
| 3441 | ZSI |
| 3398 | pytz |
| 3386 | ZODB3 |
| 3244 | zc.recipe.filestorage |
| 3128 | Pygments |
| 3116 | textile |
| 3092 | Elixir |
| 2891 | zope.deferredimport |
| 2875 | WSGIUtils |
| 2753 | py2app |
| 2731 | AuthKit |
| 2408 | buildutils |
| 2233 | bdist_mpkg |
| 2192 | zope.proxy |
| 2175 | MySQL-python |
| 2156 | readline |
| 2143 | memojito |
| 2011 | zope.component |
| 1987 | zc.recipe.zope3instance |
| 1954 | zope.exceptions |
I already explained this, but let me point out one more time, that the top packages on this list are surely the ones that don’t hide their old versions. Also, keep in mind that many packages have their own download locations and don’t use PyPI for this.
For those interested, here’s the code that generated this list (I used the BeautifulSoup screen scraping library):
import xmlrpclibimport urllib2from urllib import quotefrom BeautifulSoup import BeautifulSoup
server = xmlrpclib.Server('http://pypi.python.org/pypi')
spec={}operator='and'
packages=[package['name'] for package in server.search(spec,operator)]
downloaded=[]downloaded_names=[]
for package in packages: downloads=0 package_releases=server.package_releases(package) for release in package_releases: try: package_url='http://pypi.python.org/pypi/%s/%s' % (quote(package),release) except KeyError: continue try: text=urllib2.urlopen(package_url).read() except urllib2.HTTPError: continue soup=BeautifulSoup(text) for row in soup.findAll('tr')[1:-1]: columns=row.findAll('td') if len(columns)>=4: downloads=downloads+int(columns[4].string) if not package in downloaded_names: downloaded_names.append(package) downloaded.append({'package':package,'times':downloads})
top=sorted(downloaded,lambda x,y:cmp(y['times'],x['times']))
print "
Most downloaded packages for spec %s
" % str(spec)for package in top: print "%8d -->" % package['times'], print package['package']
That’s it for now. Next time I will give my attention to Zope 3’s libraries (though you can see quite a few of them on the general Python list above). We’ll see how that goes.
Carlos de la Guardia: Python Package Index Greatest Hits
Originally from Planet Plone
Ploneability Higher Education Workshop: November 7 Posted by Robert Nagle on 16 Sep 2007 at 9:12 pm under attending, geekevents, Python/Zope/Plone, Texas/Regional I’ll probably be attending the Ploneability Higher Education workshop at University of Houston on November 7. Registration
‘http://stormp.kk.dk/linkme.asp?kkbbase=www&kkbtype=list&kkbccl=ccl= %s’ % request.QUERY_STRING"
Resultatvisninger i Plone — Københavns Biblioteker
Originally from del.icio.us/tag/plone by joan_larsen
Resultatvisninger i Plone — Københavns Biblioteker
Originally from del.icio.us/tag/plone by joan_larsen
<p>While we have been focused on the development of GetPaid (get the latest at <a href=”http://code.google.com/p/getpaid/downloads/list”>http://code.google.com/p/getpaid/downloads/list</a> ), there are a number of new products out, or about to be, so I have updated and reorganized a bit the <a title=”Plone Commerce Background” href=”../why/plone-commerce-background”>Plone Commerce Background </a>page. For convenience, I am copying the new stuff here. <br /><br />NOTE: I am not endorsing any of these and this is not intended to be a review of these products. If you are seeking a commerce solution, it is recommended that you carefully review the products in question for quality of the framework, interface, and support/community – in addition to the features – before making a choice. <br /><br />In the order from most recent (for my discovery of them):<br /></p>
<ul><li>Sustainable Shop (ssShop): according to one of the developers, it is “an out-of-the-box online shop which includes, amongst other things, paid-for downloads, and product variants, as well as regular shop products”. The product was based on work for the Royal Scottish Country Dance Society, and can be seen in action here: <a href=”http://www.rscds.org/shop”>http://www.rscds.org/shop</a> . Pending a 1.0 final release shortly, for now the code can be found at: <a href=”http://ssplone.svn.sourceforge.net/viewvc/ssplone/ssShop/trunk/”>http://ssplone.svn.sourceforge.net/viewvc/ssplone/ssShop/trunk/</a></li><li>Emencia Commerce Suite: An Open Source commerce product built on Zope / Zwook / relational database. Handles country, shipping, taxes, order workflow, currencies, customers, catalog, coupons/promotions, and orders management. Find more information at <a href=”http://www.emenciacommerce.com/en/aboutecs/functionalities”>http://www.emenciacommerce.com/en/aboutecs/functionalities</a> </li><li>Quintagroup Ecommerce Solution: The first for-fee (not free) Plone commerce product I have come across (costs US$430), it is designed to run an online store as “a universal tool for managing products in the online store”. It is developed for Plone 2.5 and uses SimpleCartItem (see below) and seems to consist of a product content type and some portlets, inventory function, as well as a currency preference feature. Find more on the product at <a href=”http://quintagroup.com/solutions/e-commerce “>http://quintagroup.com/solutions/e-commerce </a><br /> </li><li>SimpleCartItem: Developed by the folks at netCorps, SimpleCartItem is designed to provide a basic content type that integrates with online stores such as PayPal store and allows for various attributes on an item (color, size, etc). It works with both Plone 2.1 and 2.5 and draws from PloneMall and PlonePayPal. It appears to also work with 2Checkout processor. Find more at <a href=”http://plone.org/products/simplecartitem”>http://plone.org/products/simplecartitem</a> </li></ul>
<p><br />There are more all the time, so it looks like we are getting some healthy competition in the Plone commerce space finally! <br /></p>
Get Paid: Plone Ecommerce Space Growing Fast!
Originally from Planet Plone
two experiments in the Python environment. The first is virtualenv, which is a rethinking of virtual-python.py, and my attempt to move away from workingenv. It works mostly like virtual-python.py, and on systems where it works (not Windows, nor Framework Mac Python) I think it works considerably better than workingenv. No more not a setuptools’ site.py, in particular. The basic technique is that it creates/copies a new python executable, and anything that uses that executable (including a script that references that executable with #!) will use that environment.
On the systems where it doesn’t work, I’m not quite sure what to do. The problem with the Mac is that sys.prefix is not determined by the location of the python executable, it’s hard-coded in some fashion. I asked about it on distutils-sig and got some response, but haven’t figured out any solution yet.
On Windows similarly sys.prefix is not determined by the executable location. What it’s determined by there I don’t know — the location of python25.dll, something in the registry? If I could figure it out, perhaps this could work there too — the existance of symlinks isn’t as important as it was with virtual-python.py.
If I can get these figured out, I think this will be a much happier experience than workingenv, and a somewhat friendlier experience than virtual-python.py. On non-Mac posix systems it works well right now.
The other experiment is in buildutils (downloadable with Mercurial): a new command python setup.py bundle, run in the application package you want to bundle. This creates a directory with all the dependencies of the application, and scripts that load up the appropriate dependencies. You can then ship the entire thing in a zip file as a runnable application that doesn’t require any installation except for unpacking.
Actually creating the bundle can be a little finicky, because easy_install has a tendency to prefer things on the local machine even though it shouldn’t. Probably it would be best to run this inside a virtualenv; when you are done you can also feel more confident that you’ve actually included all the dependencies (if you use –no-site-packages when creating the virtualenv).
Anyway, while both of these are a little incomplete I’m feeling optimistic about them, and I’m hoping intrepid souls can give feedback on how they work.
Ian Bicking: 2 Python Environment Experiments
Originally from Planet Plone