[Distutils] Making pip and PyPI work with conda packages

[Nick Coghlan]

On 21 May 2015 at 05:05, Wes Turner <wes.turner at gmail.com> wrote:
>
>
> On Wed, May 20, 2015 at 12:13 PM, Chris Barker <chris.barker at noaa.gov>
> wrote:
>>>>
>>>> The package includes its build recipe in info/recipe
>>>
>>>
>>> very cool -- I hadn't seen that -- I'll go take a look at some packages
>>> and see what I can find.
>>
>>
>> Darn -- the recipe is not there in most (all?) of the packages that came
>> from Anaconda -- probably due to the legacy issues David referred to.
>
> The other day, I upgraded the version of conda-recipes/arrow to v0.5.4, and
> added ofxparse.
>
> I should probably create some sort of recurring cron task to show how far
> behind stable the version number in the meta.yaml is. (see: conda skeleton
> --version-compare issue/PR (GH:conda/conda-build))

https://release-monitoring.org/ is a public service for doing that
(more info on supported upstream backends at
https://release-monitoring.org/about, more info on the federated
messaging protocol used to publish alerts at
http://www.fedmsg.com/en/latest/)

Anitya (the project powering release-monitoring.org) was built as the
"monitoring" part of Fedora's upstream release notification pipeline:
https://fedoraproject.org/wiki/Upstream_release_monitoring

One of my hopes for the metadata extension system in PEP 426 is that
we'll be able to define extensions like "fedora.repackage",
"debian.repackage"  or "conda.repackage" which include whatever
additional info is needed to automate creation of a policy compliant
downstream package in a format that's a purely additive complement to
the upstream metadata, rather than being somewhat duplicative as is
the case today with things like spec files, deb control files, and
conda recipes.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia