ptone/pypi_refactor_notes.rst

## pypi_refactor_notes.rst

      
    Raw
  

              pypi_refactor_notes.rst
            
          
    Notes on PyPI Packaginator refactor


The goals:


decouple PyPI specific code from core Packaginator
allow enhanced PyPI related features for pythonpackages instance of
Packaginator


Steps in Brief:


factor out PyPI related fields into own model
factor out form and view logic
remove pypi specific references from templates
factor out djangopackages app that is a thin wrapper around the integration
of core packaginator and pypi, and add back in bits to templates

PyPI and djangopackages app should be their own repos, not bundled into
packaginator/apps
djangopackages site repo should be renamed to djangopackages.com
djangopackages.com site will need template changes to include the pypi related
information in the templates

Consideration of djangopypi from chishop

djangopypi is the meat of the chishop project which emulates pypi itself.
obviously their models are complete and thorough. They should be examined,
cribbed from or used as is.
An advantage of linking completely, is that it offers pythonpackages the latent
feature of emulating the pypi interface for uploading and provides the xmlrpc
interface for searching and downloads - not an immediate goal, but nice to have
baked in as an option.

some places found via a quick ack search:


package resource in API
grid views and view tests
on homepage: "show_pypi": category.show_pypi,
PackageAdmin
PackageForm
package.pypi
package.models
package.repos.sourceforge (uses pypi name to get sourceforge name)
package.tests.test_pulls
package.tests.test_sourceforge
templates/package/includes/_package.html
templates/package/includes/_package_form.js
templates/package/package.html
templates/package/package_list.html
templates/grid/grid_detail.html
templates/about/about.html
templates/package/category.html


how to link package to pypi data:

Because the package model will not explicitly know it has a pypi model
attached, the code that wants pypi information will need to be responsible for
extracting that information. At some point, it may be worth considering how to
generalize this. For example if a view want to include all "meta data" that is
attached to a package via various other models - but for now that should just
be left to each packaginator instance.
"
pypi model has a one-to-one field to package model
allows code using the package model to do package_instance.pypi.blah