Re: [VOTE]: Release Apache Airflow 2.0.0 form 2.0.0rc2

Whoops - I missed one reference to rc1 in the vote email when I copypastad it. :) On Sat, 12 Dec, 2020 at 20:20, Jarek Potiuk wrote: HUGE +1 (binding). * Performed all the release verifications (RAT/Signatures/SHA) * Run several combinations of Python /Backend * No more sdist problem (no mor

Re: [VOTE]: Release Apache Airflow 2.0.0 form 2.0.0rc2

HUGE +1 (binding). * Performed all the release verifications (RAT/Signatures/SHA) * Run several combinations of Python /Backend * No more sdist problem (no more sdist that is :) !) * Tested installation with providers and proper provider discovery `airflow providers list` IT'S CRAZY FAST. I had t

[VOTE]: Release Apache Airflow 2.0.0 form 2.0.0rc2

Hi my lovely Airflowers, I have cut Airflow 2.0.0 RC1. This email is calling a vote on the release, which will run for three days, until 2020-12-15T15:00:00Z https://www.timeanddate.com/worldclock/fixedtime.html?msg=8&iso=20201215T1500&p1=1440

CANCELED: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

I'm cancelling this vote -- it doesn't feel right to change what we are voting on mid-vote. And doing it now we can do it as a three day vote, so we only loose one day. New vote for 2.0.0rc2 to follow shortly On Sat, 12 Dec, 2020 at 12:25, Jarek Potiuk wrote: Ah cool. So I think we can dr

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

Ah cool. So I think we can drop sdist indeed :). I think if it is the only problem found till Monday, I would be OK in dropping sdist from 2.0.0 release then - if this is going to slow down the process by a week. I am happy to change my vote if others are happy with it. Regardless, I updated our

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

The BigQuery dataset PyPi publishes has a file.type column: Since we started publishing wheels (1.10.3) the wheel almost all of the downloads. This 2020-12-01 (picked randomly): 1.10.12bdist_wheel108311.10.12sdist121.10.1

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

Update: not provider packages, but the packages that airflow depends on. indeed all our provider/airflow package are pure python and as long as there are no "special cases" like anyone requiring source packages (for whatever reason) they *should* work. On Sat, Dec 12, 2020 at 10:48 AM Jarek Potiuk

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

It might well be, yes, that we have no such problem in the airflow package. I referred more to the provider packages. I think it would like to hear from the user why sdist was used in this case. Also, I believe there are some distros Gentoo, that always use sources for everything it can (and I am n

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

On Sat, 12 Dec, 2020 at 10:34, Jarek Potiuk wrote: So I think there will be systems where sdist is used automatically because the host system is not as close to what we use when build wheels. I think that is only a problem for wheels with binary components,but our wheels are not -- they are

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

Specifically we are not using "manylinux or manylinux2" wheels which are specifically targeting this problem: https://github.com/pypa/manylinux On Sat, Dec 12, 2020 at 10:34 AM Ash Berlin-Taylor wrote: > (After 2.0.0, for now we'll release rc2 with the same set) > > On Sat, 12 Dec, 2020 at 09:24

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

This might be an option. I asked the user what is the reason the installation was done. However I already experienced some problems with .whl files installed on different platforms. This is one of the reasons we are preparing our wheel files inside the CI container based on debian, because when th

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

(After 2.0.0, for now we'll release rc2 with the same set) On Sat, 12 Dec, 2020 at 09:24, Ash Berlin-Taylor wrote: I wonder if we should not bother releasing the sdist at all? Since our wheel is OS agnostic anyway, and wheel is much faster to install, I see little point in continuing to releas

Re: [VOTE] Release Airflow 2.0.0 from 2.0.0rc1

I wonder if we should not bother releasing the sdist at all? Since our wheel is OS agnostic anyway, and wheel is much faster to install, I see little point in continuing to release the sdist. We should have the artefacts become the source (`git archive`) and the `wheel` only I think. -ash O