Skip to main content

A Django application that emulates the Python Package Index.

Project description

DjangoPyPI 2

DjangoPyPI is a Django application that provides a re-implementation of the Python Package Index. Using Twitter Bootstrap for UI, forked from the original DjangoPyPi project, DjangoPyPi2 provides an easy to use and manage interface.

Compatibility Note

This is a fork of the original djangopypi package. This version is somewhat different than the original version by its design, and it might affect older version in that the database table names are different than the original ones. It is highly recommended that you install a fresh copy of this package and manually transfer you data from your installation.

Since the table names in this installation are different, the same database can be used for the migration. Unfortunately there are too many versions of djangopypi our there, so it’s quite dangerous to create south migrations for them. Sorry for the inconvenience.

Installation

DjangoPyPi2 is a self-contained Django project along with its apps. If you want fine-grained control, you can looks at the sources of the apps found in the djangopypi2.apps package.

The most simple way to install djangopypi2 is by:

# Make sure we run with Bash, create a virtualenv and install packages
$ bash
$ virtualenv pypi-site
$ source pypi-site/bin/activate
$ pip install django gunicorn djangopypi2

# Configure our installation (all data is kept in ~/.djangopypi2)
$ manage-pypi-site syncdb
$ manage-pypi-site collectstatic
$ manage-pypi-site loaddata initial

That’s it, we’re now ready to run our server

Running

It’s easiest to see our server running by executing:

$ gunicorn_django djangopypi2.website.settings

Then surfing to http://localhost:8000/ .

For a permanent setup, simply create a supervisor <http://supervisord.org/> configuration:

[program:djangopypi2]
user = www-data
directory = /path/to/virtualenv
command = /path/to/virtualenv/bin/gunicorn_django djangopypi2.website.settings

Package upload directory

Packages are uploaded to ~/.djangopypi2/media/dists/ by default.

You can change this setting by setting up a Django project with more specific settings, or have a look at the admin interface’s Global Configuration section to see if you configure your desired behavior in there.

Uploading to your PyPI

Assuming you are running your Django site locally for now, add the following to your ~/.pypirc file:

[distutils]
index-servers =
    pypi
    local

[pypi]
username:user
password:secret

[local]
username:user
password:secret
repository:http://localhost:8000/pypi/

Uploading a package: Python >=2.6

To push the package to the local pypi:

$ python setup.py register -r local sdist upload -r local

Uploading a package: Python <2.6

If you don’t have Python 2.6 please run the command below to install the backport of the extension for multiple repositories:

$ easy_install -U collective.dist

Instead of using register and dist command, you can use mregister and mupload which are a backport of python 2.6 register and upload commands that supports multiple servers.

To push the package to the local pypi:

$ python setup.py mregister -r local sdist mupload -r local

Installing a package with pip

To install your package with pip:

$ pip install -i http://my.pypiserver.com/simple/ <PACKAGE>

If you want to fall back to PyPi or another repository in the event the package is not on your new server, or in particular if you are installing a number of packages, some on your private server and some on another, you can use pip in the following manner:

$ pip install -i http://localhost:8000/simple/ \
  --extra-index-url=http://pypi.python.org/simple/ \
  -r requirements.txt

(substitute your djangopypi2 server URL for the localhost one in this example)

The downside is that each install of a package hosted on the repository in --extra-index-url will start with a call to the first repository which will fail before pip falls back to the alternative.

History

0.5.3 (2012-10-04)

  • Remove policy from MirrorSite

  • Redirect to first enabled mirror site when package is not found locally

0.5.2 (2010-10-03)

  • Organize code in distutils views

  • Detect binary platform (in case of bdist_*) from filename

0.5.1 (2012-10-03)

  • Provide ready-to-deploy Django project within the package

0.5.0 (2012-10-03)

  • Removed south support (too many changes), hopefully added in a future version

  • Added bootstrap-based user interface

  • Split djangopypi to several Django apps

  • Switched to relative imports

  • All configuration resides in the database and editable from the admin

  • Static files are automatically served when DEBUG = True

  • Removed loadclassifiers command

  • Contains fixtures with initial data for all configuration models

0.4.4 (2012-04-18)

  • xmlrpc bug fixes

  • CSRF token template tags on forms

  • Transaction bug fixes

  • Switched to logging over stdout

  • Proxy simple and detail views when necessary

  • Removed unused legacy view, submit_package_or_release

  • ppadd management command working again

0.4.3 (2011-02-22)

  • Moved xmlrpc views into views folder

  • Moved xmlrpc command settings to the settings file

  • Cleaned up xmlrpc views to remove django.contrib.sites dependency

0.4.2 (2011-02-21)

  • Added CSRF support for Django>=1.2

  • Added conditional support to proxy packages not indexed

0.4.1 (2010-06-17)

  • Added conditional support for django-haystack searching

0.4 (2010-06-14)

  • ‘list_classifiers’ action handler

  • Issue #3: decorators imports incompatible with Django 1.0, 1.1

  • RSS support for release index, packages

  • Distribution uploads (files for releases)

0.3.1 (2010-06-09)

  • Installation bugfix

0.3 (2010-06-09)

  • Added DOAP views of packages and releases

  • Splitting djangopypi off of chishop

  • Switched most views to using django generic views

Backwards incompatible changes

  • Refactored package/project model to support multiple owners/maintainers

  • Refactored release to match the metadata only that exists on pypi.python.org

  • Created a Distribution model for distribution files on a release

0.2.0 (2009-03-22)

  • Registering projects and uploading releases now requires authentication.

  • Every project now has an owner, so only the user registering the project can add releases.

  • md5sum is now properly listed in the release link.

  • Project names can now have dots (‘.’) in them.

  • Fixed a bug where filenames was mangled if the distribution file already existed.

  • Releases now list both project name and version, instead of just version in the admin interface.

  • Added a sample buildout.cfg. Thanks to Rune Halvorsen (runeh@opera.com).

Backwards incompatible changes

  • Projects now has an associated owner, so old projects must be exported and imported to a new database.

0.1.0 (2009-03-22)

  • Initial release

Authors/Contributors

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

djangopypi2-0.5.3.tar.gz (123.6 kB view hashes)

Uploaded Source

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page