aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Farner <wfar...@apache.org>
Subject Re: [PROPOSAL] Switch our Python build to virtualenv+setup.py+tox
Date Mon, 20 Oct 2014 17:40:07 GMT
Overall this sounds good to me.  What do you propose to take over for
thrift compilation?

-=Bill

On Fri, Oct 17, 2014 at 5:35 PM, Kevin Sweeney <kevints@apache.org> wrote:

> Hi all,
>
> We've had a lot of flakiness in our Python build recently, related to our
> position of being early adopters of the pants python tooling. This has lead
> to CI flakiness and has put us in a position of being user support for
> Pants just for people to be able to build our project. I'd like to gauge
> the community's support for moving to a more standard Python workflow.
>
> Background
>
> Right now we use pants for the several stages of our python build:
>
>    - Resolving dependencies from PyPI (BUILD files instead of
>    requirements.txt).
>    - Generating Python code from our Thrift IDLs (python_thrift_library in
>    BUILD files).
>    - ./pants setup_py - Auto-generating sdists (.tar.gz with a setup.py)
>    consumable as downstream libraries.
>    - ./pants goal test - Running Python unit tests in a virtualenv with
>    py.test.
>    - ./pants build - Creating deployable artifacts (.pex).
>
> Proposal
>
> I'd like to propose we consider replacing parts of this build with more
> standard mechanisms.
>
> Specifically I'd like to replace the use of pants as the test runner with
> tox <https://tox.readthedocs.org/en/latest/> and to replace pants as the
> tool for deployable artifacts (used in the Vagrant environment for
> tutorials and end-to-end tests) with bdist_wheel and pip install.
>
> Users would retain the ability to use PEX at deploy-time if they want, as
> we'll still be exporting a standard setup.py packages.
>
> I'm sure there's a fair amount of work to get there, but before we start
> down that path I'd like to come to consensus about whether this is a good
> idea.
>
> Please discuss.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message