readthedocs / pydoc.io Goto Github PK

Uh, we should have these.

We want the /autoapi/index.html as /index.html. The module listing is in the correct order, and we have knowledge of all the packages there. Additionally, do we need the page toc to display on the index page?

We need to update our standard config with some of the more common extension formats that we see. We also likely need to be smarter about the data we're pulling out of docstrings, as I think napolean has a couple different formats, and they might be mutually exclusive. So we'd need to properly configure it for the right format of docstring.

Currently this is manually maintained. Use list_packages on RPC API.

Automate pulling in projects from the API as they are updated

Fuzzy search for project names

Hey all,

We started this project with a grant from Mozilla, but we haven't been able to find funding for ongoing development & maintenance of the project. It is mostly a distraction from our work on Read the Docs itself. It's a project that I still think has value, but we aren't able to focus on it and provide the resources it needs to flourish.

If anyone else in the community wants to step up and work on this, we're happy to give you access to maintain the repo. However, we are currently planning on having it shut down in the next few months, if nobody steps up to help maintain it.

Cheers,
Eric

Some UX thoughts for the front page:

• Description of what is Pydoc
• When listing projects, list the last built projects and multiple versions for the package
• Also display meta data on package or release
• Prominent search
• Maybe fancy graphs on packages built?

Optionally, maybe the recent list is a separate page and the front page is nothing but copy and fuzzy search

Support pulling: package meta data, name, version, packages, possibly python 2/3 support?

Abstract doc storage to local and cloudfiles/s3/etc/etc. This piece could theoretically be reused on RTD as well, so perhaps its best to design with that in mind.

For now, the option will exist in the configuration. We'll want to expose a version selection api similar to what we're doing on RTD. Perhaps the client side code can be generalized more though -- instead of expecting html content back from the API request, expect an object instead.

There is some work in our current ops tree. Break this out and extend it in its own tree.

Integrate with libraries.io for trending and popular package information. This will be used on the front page to link to documentation.

Keep in memory or cache the response or something. We just need this to update periodically for the front page display.

There is a lot of unused cruft in this repo, and a lot of patterns we don't use in any other property. This should all be cleaned up.

For a package foo, the method signatures read foo.method(), etc. This should be less verbose, and should probably be a change to the template member nesting.

Perhaps move this off the front page? Or even if we include this on the front page, it might help to have more metadata displayed in the list:

• Last update (X hours ago)
• Package description
• Version?

I recognize that this repo may well be about to turn unmaintained, but I still want to give a heads-up to the community about upcoming changes in the Python Package Index, in case it affects y'all.

I'm the project manager for the new Python Package Index (Warehouse), which is currently in pre-production at http://pypi.org/ . On the Warehouse roadmap, it looks like the full switch will happen sometime in April, so here's a heads-up about why we're switching, what's changed, and what to expect. (A bunch of this is not directly relevant to pydoc but I thought you might want to know anyway!)

The legacy PyPI site at https://pypi.python.org started in the early 2000s. In recent years, users faced outages, malicious packages, and spam attacks, and the legacy codebase made it hard to maintain and even harder to develop new features.

The new PyPI has a far more modern look, and is up-to-date under the hood as well; a proper web framework (Pyramid), 100% backend test coverage, and a Docker-based development environment, make it easier for current and new developers to maintain it and add features.

Thanks to Mozilla's Open Source Support funding, developers have added many new features, overhauled infrastructure, and made steady progress towards redirecting traffic to the new site and shutting down the old one. As of the middle of last year, package releases must go through the new PyPI, and as of late February, new user account registration is only available on the new site. The full switch will include redirecting browser and pip install traffic from the old site; then, sometime in late April or early May, the legacy site will be entirely shut down.

Thanks to redirects, you may not have to change anything immediately. Here's a migration guide.

Some new PyPI features:

• mobile-responsive UI
• chronological release history for each project (example)
• easy-to-read project activity journal for project maintainers
• better search and filtering
• support for multiple project URLs (e.g., for a homepage and a repo)
• user-visible Gravatars and email addresses for maintainers
• no need to "register" a project before initial upload
• far better backend infrastructure, reducing the frequency of outages

Things that are going away, or already have (sometimes for policy or spam-fighting reasons), include:

• pythonhosted.com documentation hosting (pypi/warehouse#582)
• download counts visible in the API (instead, use the Google BigQuery service)
• GPG/PGP signatures for packages (still visible in the Simple Project API per PEP 503, but no longer visible in the web UI
• key management: PyPI no longer has a UI for users to manage their GPG or SSH public keys
• package maintainers being able to upload a new release via the web UI (instead, the recommended command-line tool is Twine)
• package maintainers being able to log in and update release descriptions via the web UI (to update release metadata, they need to upload a new release; see distutils-sig discussion)
• OpenID and Google auth login
• users being able to upload a package without verifying their email address with PyPI first
• HTTP access to APIs; now it's HTTPS-only

And in the works:

• PEP 541 will enable more timely package takeovers, as people get package names transferred to them after conflict resolution
• Now that PEP 566 has been approved, developers are working to get Markdown supported for README files on PyPI

For future updates, please sign up for the low-traffic PyPI announcements email list.

Thank you for integrating with PyPI, and please let us know if you have any questions or problems with the new site!

The package_info field isn't currently being updated properly. We should be capturing more info here.

Make local-ish overrides to the theme to fit wider nav content, etc. Later on, we may move back to a custom theme that supports some of the additional features around API reference (scrolling, fixed header, etc)

The theme should have a version select dropdown, optional of course. It should point to arbitrary urls as well, for maximum flexibility. This would be used as html_theme_options.

Force them on project configuration