headers
Ryan McGuire | 10 Feb 2011 00:40
Gravatar

Would PyPI be a welcome place for Blogofile plugins?

Hello,

I'm the author of Blogofile (http://www.blogofile.com) and am creating
a new plugin system that will allow people to install third party
Python modules as plugins to Blogofile. There is a current discussion
on this topic here:

http://groups.google.com/group/blogofile-discuss/t/18eebfab6f736699

The best suggestion for how to do this so far is to just use Python
eggs for plugins, and we'd be able to leverage the existing
functionality of easy_install or pip for versioning and dependency
management. However, Blogofile plugins are not necessarily Python
source code, they could just be CSS files for a Blogofile theme. The
idea is to wrap this content in a Python module and retrieve this
content via pkg_resources.

Would the inclusion of such modules, that have no actual Python code
in them, but do enhance an existing Python tool on PyPI (blogofile) be
an abuse of PyPI? Could a trove classifier be setup to indicate that
these are Blogofile plugins?

This is a crosspost from a question I asked on the PyPI support
tracker (http://is.gd/pnbxOk), and it was suggested there to bring
this discussion to catalog-sig.

Thanks,
Ryan McGuire
Permalink | Reply | 0 comments |
headers
P.J. Eby | 10 Feb 2011 04:08
Gravatar

Re: Would PyPI be a welcome place for Blogofile plugins?

At 06:40 PM 2/9/2011 -0500, Ryan McGuire wrote:
>The
>idea is to wrap this content in a Python module and retrieve this
>content via pkg_resources.

Just as an FYI, the suggested approach for something like this would 
be to bundle the data under the project's .egg-info, and use the 
pkg_resources.metadata_* APIs to access them.  In this way, you don't 
have to make any fake Python packages or modules to install and 
access the data.  You only need modules if the plugin does in fact 
contain code.

See the EggTranslations project for an example of doing this with i18n plugins:

   http://chandlerproject.org/Projects/EggTranslations

(Indeed, if you plan for plugins' resources to be translatable, you 
may simply want to use EggTranslations as your resource lookup mechanism.)

Also as an FYI, pkg_resources includes APIs that are intended to make 
it easy to find and load plugins from designated plugin directories, e.g.:

   http://peak.telecommunity.com/DevCenter/PkgResources#locating-plugins
Permalink | Reply | 0 comments |
headers
Martin v. Löwis | 14 Feb 2011 23:37
Picon
Gravatar

Scheduled PyPI outage on Friday

Due to a Debian upgrade, PyPI will be offline on Friday between 9:00 UTC
and 11:00 UTC, most likely for less than an hour.

Regards,
Martin
Permalink | Reply | 8 comments |
headers
Chris Withers | 17 Feb 2011 19:13
Picon

argparse dns failures

Hi Guys,

http://pypi.python.org/simple/argparse/ has some links to 
http://argparse.python-hosting.com/ which now gives a DNS error.

As a result, anyone installing argparse via a packaging tool gets scary 
noise when installing.

How can we make these links go away?
Does Steven have to manually go and edit the 0.6.x releases to remove them?

cheers,

Chris

--

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk
Permalink | Reply | 3 comments |
headers
Chris Withers | 17 Feb 2011 19:12
Picon

argparse dns failures

Hi Guys,

http://pypi.python.org/simple/argparse/ has some links to 
http://argparse.python-hosting.com/ which now gives a DNS error.

As a result, anyone installing argparse via a packaging tool gets scary 
noise when installing.

How can we make these links go away?
Does Steven have to manually go and edit the 0.6.x releases to remove them?

cheers,

Chris

--

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk
Permalink | Reply | 0 comments |
headers
Martin v. Löwis | 17 Feb 2011 23:15
Picon
Gravatar

Re: argparse dns failures

> Does Steven have to manually go and edit the 0.6.x releases to remove them?

Exactly so. Alternatively, entirely removing this release would also help.

Regards,
Martin
Permalink | Reply | 2 comments |
headers
Chris Withers | 18 Feb 2011 08:27
Picon

Re: argparse dns failures

Steven, any chance you could remove the links?

Removing the releases is pretty anti-social, in case someone has those 
versions pinned...

cheers,

Chris

On 17/02/2011 22:15, "Martin v. Löwis" wrote:
>> Does Steven have to manually go and edit the 0.6.x releases to remove them?
>
> Exactly so. Alternatively, entirely removing this release would also help.
>
> Regards,
> Martin
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

--

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk
Permalink | Reply | 1 comment |
headers
monitor | 18 Feb 2011 11:40

[monit] pypi.python.org - Connection failed

Connection failed Service pypi.python.org 

	Date:        Fri, 18 Feb 2011 04:40:56 -0600
	Action:      alert
	Host:        jacobian.org
	Description: failed protocol test [HTTP] at INET[pypi.python.org:80] via TCP

Your faithful employee,
monit
Permalink | Reply | 0 comments |
headers
monitor | 18 Feb 2011 12:33

[monit] pypi.python.org - Connection succeeded

Connection succeeded Service pypi.python.org 

	Date:        Fri, 18 Feb 2011 05:33:47 -0600
	Action:      alert
	Host:        jacobian.org
	Description: connection succeeded to INET[pypi.python.org:80] via TCP

Your faithful employee,
monit
Permalink | Reply | 0 comments |
headers
Tarek Ziadé | 18 Feb 2011 13:12
Picon
Gravatar

A prerelease.pypi.python.org

Hello

In my blog entry about dev releases at PyPI -
http://tarekziade.wordpress.com/2011/02/15/do-not-upload-dev-releases-at-pypi

Glyph proposed this:

  "...wouldn’t it be plausibIe to fix for all versions of Python
packaging tools by making a prerelease.pypi.org staging area, which
could be explicitly selected / enabled?"

I think this is a great idea.

1/ all tools are already able to point to another PyPI root
2/ it would allow users to opt in for "unstable releases"

For this to work, we would need the "prerelease" index to also publish
the "final" index content, because most tools are still unable to
merge repositories, so I am not sure about how this could be done.

Maybe "prerelease" could be a simple alias on the same server, and we
detect via the virtual host it was used so we can decide:

1/ if the package being uploaded is marked as not final
2/ if 'non final' packages are included in browsing requests

Cheers
Tarek

--

--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane