To use or not to use: packaged flask

[Alec Leamas]

Hi out there!

I'm dipping my toes in flask, completely newbie. Doing so, I see a lot 
of fedora flask packages, but no-one anywhere recommends using these - 
it's all about pypi.

I "think" I prefer the packaged version, partly because I'm using 
another package with native code (which, as I understand it, isn't that 
easy to make a linux pypi package of). However, I'm stuck at the very 
beginning:

    $  ./run_flask
    ...
    ImportError: No module named 'flask.cli'

So, my question: is it possible to run a flask application using the 
packaged components similar to run_flask above, in any way? If so, how?


Cheers!

--alec

[Petr Viktorin]

On 01/12/2017 10:44 AM, Alec Leamas wrote:
>  Hi out there!
>
>  I'm dipping my toes in flask, completely newbie. Doing so, I see a lot
>  of fedora flask packages, but no-one anywhere recommends using these -
>  it's all about pypi.
>
>  I "think" I prefer the packaged version, partly because I'm using
>  another package with native code (which, as I understand it, isn't that
>  easy to make a linux pypi package of). However, I'm stuck at the very
>  beginning:
>
>     $  ./run_flask
>     ...
>     ImportError: No module named 'flask.cli'
>
>  So, my question: is it possible to run a flask application using the
>  packaged components similar to run_flask above, in any way? If so, how? 
What is ./run_flask? Is this a script you wrote yourself?

On my Fedora 25, I can import flask.cli from the system packages just 
fine. But note that Fedora 24 has an older version of Flask packaged – 
one that doesn't include flask.cli yet.

Generally, you're better off using a virtual environment and PyPI, 
unless you're making some software specifically for Fedora.
Packages with native code aren't as much of a problem nowadays as they 
used to be, but if you still run into trouble, we'll be happy to help :)


-- 
Petr Viktorin

[Alec Leamas]

On 12/01/17 11:53, Petr Viktorin wrote:
>  On my Fedora 25, I can import flask.cli from the system packages just
>  fine. But note that Fedora 24 has an older version of Flask packaged –
>  one that doesn't include flask.cli yet. 
Ah... that sorts things out. Time to upgrade...

>  Packages with native code aren't as much of a problem nowadays as
>  
they used to be, but if you still run into trouble, we'll be happy to help

It's "my" code, I'm upstream for an old package for which I'm about
to 
add a python API. Haven't found any pointer how to make pypi package 
with linux native code... have you?


Cheers!

--a

[Alec Leamas]

On 12/01/17 12:02, Alec Leamas wrote:


>  It's "my" code, I'm upstream for an old package for
> which I'm about to
>  add a python API. Haven't found any pointer how to make pypi package
>  with linux native code... have you? 
At a second thought, I don't think I wan't this. My users will  need the 
real package (lirc) anyway; this is compiled code which typically is 
installed using package managers. Adding the python API to the core 
package means that neither building nor headers are required after 
installing the package, and I'm pretty sure pypi doesn't solve that in a 
better way.

So, this is really about how to use the system library within the 
virtualenv (I know that), and updating to F25.  Seems reasonable


Cheers!

--alec

[Nick Coghlan]

On 12 January 2017 at 21:26, Alec Leamas <leamas.alec(a)gmail.com&gt; wrote:
>  On 12/01/17 12:02, Alec Leamas wrote:
> > It's "my" code, I'm upstream for an old package for which I'm
> about to
> > add a python API. Haven't found any pointer how to make pypi package
> > with linux native code... have you?
>
>  At a second thought, I don't think I wan't this. My users will  need the
>  real package (lirc) anyway; this is compiled code which typically is
>  installed using package managers. Adding the python API to the core package
>  means that neither building nor headers are required after installing the
>  package, and I'm pretty sure pypi doesn't solve that in a better way. 
The main cases where I've personally found "system package only" to be
a genuine pain is when doing cross-version compatibility testing with
tox for projects that still support Python 2.6.

As a specific example, you can't readily run the Anitya tests under
Python 2.6 on Fedora, as even though there's a python26 package,
there's no corresponding RPM bindings for it, and hence "import rpm"
fails even with --system-site-packages enabled.

The same problem comes up in reverse on RHEL/CentOS where the newer
runtimes available via EPEL or Software Collections are missing most
system packages and hence rely almost entirely on PyPI.

That said, there's an eminently practical way to avoid those problems
in many cases: run a recent Fedora container image atop a RHEL or
CentOS container host rather than running directly on the host.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan(a)gmail.com   |   Brisbane, Australia