aurora-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "brian wickman (JIRA)" <>
Subject [jira] [Commented] (AURORA-368) newer pants/commons lib break aurora packaging
Date Tue, 29 Apr 2014 19:00:18 GMT


brian wickman commented on AURORA-368:

it's true that the one on pypi is a valid .tar.gz, but it's transitively finding another protobuf-2.5.0.tar.gz
from from a valid rel link.  twitter.common.python follows rel links by default,
whereas pip does not.  the followed link is clobbering the one from pypi.

the minimum change here is to probably disable following rel links by default in twitter.common.python
and mint a new pants that allows this to be configurable in python-setup.  the longer term
is to make it configurable on a per-requirement basis but a bit more effort.

i will try to get to publishing a new version today.  in the meantime, you can unblock yourself
(locally) by dropping a proper protobuf-2.5.0-tar.gz into the third_party directory at the
root of your aurora repository.  i believe pants will short circuit and select this one. 
if not, dropping the egg there will _definitely_ short circuit the bad remote .tar.gz

> newer pants/commons lib break aurora packaging
> ----------------------------------------------
>                 Key: AURORA-368
>                 URL:
>             Project: Aurora
>          Issue Type: Bug
>          Components: Build, Packaging
>    Affects Versions: 0.5.0
>            Reporter: Bhuvan Arumugam
>         Attachments: AURORA-368.out
> Ever since pants and commons library were upgraded, we are unable to package gc_executor
binary. If it matter, we are using OEL6 with py26. Refer to attachment for PANTS_VERBOSE output.
> It complain following error:
> {code}
> Untranslateable: Package SourcePackage(u'')
is not translateable.
> {code}

This message was sent by Atlassian JIRA

View raw message