pkgme-devs team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On 30 July 2012 16:29, Allison Randal <allison@xxxxxxxxxx> wrote:
...
>
> Does it still try to run setup.py to figure out Python packages? Or, does it
> extract useful snippets of text from the setup.py? Or, ignore setup.py
> entirely?
>

Ignores setup.py entirely.

It's actually multiple (well, two) backends that share a bunch of
common code: the pdf backend and the binary backend subclass a
MetadataBackend class.

We haven't done a Python one for a few reasons:
 a) our focus is running this code on pkgme-service.canonical.com and
the easiest way, running setup.py, involves running arbitrary user
code, which we are not interested in
 b) our benevolent corporate overlords have yet to prioritize Python.

I've been toying with the idea of writing a Python backend that uses
the ``ast`` module to parse setup.py.

>> What's driving the requirement for varying the source format?
>>
>> Overall, I'd recommend starting with lp:pkgme-devportal and patching
>> it if it doesn't meet your needs. We probably want it to work for both
>> ARB & commercial apps.
>
>
> Extras does have some unique output requirements such as:
>
> - The version in debian/changelog has -extras12.04.1 appended to it.
> - The package installs in /opt/extras.ubuntu.com/pkgname (last I checked you
> install in /opt/pkgname)

These seem like make-work to me, but sure, that could be easily accommodated.

> - They're generally native packages rather than tarball releases.

pkgme just moved away from native packages, fwiw.

> So, I'm not sure if it makes sense to have a separate extras backend (that
> reuses a lot of behavior from the devportal one), or to patch in some small
> alterations to the existing devportal backend. I'll take a look at the
> devportal branch.
>

I'm not 100% sure either. The pkgme-devportal branch is definitely the
place to start though.

jml