I suggest not adopting pipenv. It has a nice "first five minutes" demo but
it's simply not baked enough to depend on as a swap in pip replacement. We
are in the process of removing it after finding several serious bugs in our
POC of it.
On Thu, Oct 4, 2018, 20:30 Alex Guziel
wrote:
> FWIW, there
FWIW, there's some value in using virtualenv with Docker to isolate
yourself from your system's Python.
It's worth noting that requirements files can link other requirements
files, so that would make groups easier, but not that pip in one run has no
guarantee of transitive dependencies not conflic
Hi Jarek,
Thanks for bringing this up. I missed the discussion on Slack since I'm on
holiday, but I saw the thread and it was way too interesting, and therefore
this email :)
This is actually something that we need to address asap. Like you mention,
we saw it earlier that specific transient depen
Thanks Jakob!
I think that this is a huge risk of Slack.
I am not against Slack as a support channel, but it is a slippery slope to
have more and more decisions/conversations happening there, contrary to
what we hope to achieve with the ASF.
When we are starting to discuss issues of development,
Thanks for pointing it out Jakob.
I am still very fresh in the ASF community and learning the ropes and
etiquette and code of conduct. Apologies for my ignorance.
I re-read the conduct and FAQ now again - with more understanding and will
pay more attention to wording in the future. As you mentione
> TL;DR; A change is coming in the way how dependencies/requirements are
> specified for Apache Airflow - they will be fixed rather than flexible (==
> rather than >=).
> This is follow up after Slack discussion we had with Ash and Kaxil -
> summarising what we propose we'll do.
Hey all. It's gr
You should run `pip check` to ensure no conflicts. Pip does not do this on
its own.
On Thu, Oct 4, 2018 at 9:20 AM Jarek Potiuk
wrote:
> Great that this discussion already happened :). Lots of useful things in
> it. And yes - it means pinning in requirement.txt - this is how pip-tools
> work.
>
Great that this discussion already happened :). Lots of useful things in
it. And yes - it means pinning in requirement.txt - this is how pip-tools
work.
J.
Principal Software Engineer
Phone: +48660796129
On Thu, 4 Oct 2018, 18:14 Arthur Wiedmer, wrote:
> Hi Jarek,
>
> I will +1 the discussion
Hi Jarek,
I will +1 the discussion Dan is referring to and George's advice.
I just want to double check we are talking about pinning in
requirements.txt only.
This offers the ability to
pip install -r requirements.txt
pip install --no-deps airflow
For a guaranteed install which works.
Several d
If I remove the Flask-AppBuild pinning to 1.11.0 then it uncovers a Jinja2
conflict which is baffling because I don't see anywhere in the graph that
jinja2 >=2.10 is required.
Could not find a version that matches
jinja2<2.9.0,>=2.10,>=2.4,>=2.5,>=2.7.3,>=2.8
Tried: 2.0, 2.1, 2.1.1, 2.2, 2.2.1, 2.
Relevant discussion about this:
https://github.com/apache/incubator-airflow/pull/1809#issuecomment-257502174
On Thu, Oct 4, 2018 at 11:25 AM Jarek Potiuk
wrote:
> TL;DR; A change is coming in the way how dependencies/requirements are
> specified for Apache Airflow - they will be fixed rather tha
Thank you for the response Ash.
Even with your suggestion, there appear to be version conflicts all over
the place. Can you get this Pipfile to install because I cannot?
*Pipfile:*
[[source]]
url = "https://pypi.python.org/simple"; [[source]]
verify_ssl = true
name = "pypi"
[packages]
apache-ai
whoops remove the [[source]] at the end of the url = "
https://pypi.python.org/simple"; that is a typo.
On Thu, Oct 4, 2018 at 11:26 AM Kyle Hamlin wrote:
> Thank you for the response Ash.
>
> Even with your suggestion, there appear to be version conflicts all over
> the place. Can you get this
TL;DR; A change is coming in the way how dependencies/requirements are
specified for Apache Airflow - they will be fixed rather than flexible (==
rather than >=).
This is follow up after Slack discussion we had with Ash and Kaxil -
summarising what we propose we'll do.
*Problem:*
During last few
Hi Björn,
We also sometimes require manual validation, and though we haven't yet
implemented this, I imagine you could store the approved/unapproved status
of the job in a database, expose it via an API, and write an Airflow sensor
that continuously polls that API until the status becomes "approve
Hi all,
In some of our workflows we require a manual validation step, where some
generated data has to be reviewed by an authorised person before the workflow
can continue. We currently model this by using a custom dummy operator that
always fails. After the review, we manually mark it as succe
We've committed a fix for this to master and will include it in a 1.10.1
https://github.com/apache/incubator-airflow/commit/fb5ffd146a5a33820cfa7541e5ce09098f3d541a
For installing in the mea time pin `Flask-AppBuilder=1.11.0'
> On 4 Oct 2018, at 00:41, Kyle Hamlin wrote:
>
> Hi,
>
> Today I
Definitely there is ;-)
Such slides & videos would be great supplement on the top of documentation.
XD
On Tue, Oct 2, 2018 at 17:01 Ash Berlin-Taylor wrote:
> Is there demand for me to give a re-run of this talk (recorded this time),
> probably over a Google Hangout or a YouTube stream?
>
> -a
I've opened an Issue/PR a while back and could use some help getting it out
the door: https://github.com/apache/incubator-airflow/pull/3914.
It's a small change (I think), but I it would be useful for us, as we're
currently reimplementing the same operator for this exact purpose.
Some code review
19 matches
Mail list logo