So I'm trying to wrap my head around packaging issues, and according to
some quick Google searches I'm not the only one.
I'm developing applications of various size for internal deployment.
When I'm actually getting the whole thing written, I've got my
initialization stub in __main__.py,
On Fri, 06 Feb 2015 16:44:26 -0500, Dave Angel wrote:
On 02/06/2015 04:35 PM, Ben Finney wrote:
Rob Gaddi rgaddi@technologyhighland.invalid writes:
So I'm trying to wrap my head around packaging issues
Congratulations on tackling this. You will likely find the Python
Packaging User Guide
On Friday, 6 February 2015 22:20:58 UTC, Rob Gaddi wrote:
I found a recommendation at https://chriswarrick.com/blog/2014/09/15/
python-apps-the-right-way-entry_points-and-scripts/ that seems to say
that I should get around this by simply having an empty __init__. I
guess I can move the
On 02/06/2015 02:56 PM, Ben Finney wrote:
It's not Setuptools per se, it's Python's import mechanism. It is a
deliberate design decision that direct import of a module makes that
module blind to its location in the package hierarchy.
That's a design decision I deplore, because it makes
On 02/06/2015 04:35 PM, Ben Finney wrote:
Rob Gaddi rgaddi@technologyhighland.invalid writes:
So I'm trying to wrap my head around packaging issues
Congratulations on tackling this. You will likely find the Python
Packaging User Guide URL:https://packaging.python.org/ helpful.
Also know
On 02/06/2015 02:20 PM, Rob Gaddi wrote:
My library code isn't in __init__.py (or previously in __main__) because
I'm trying to dodge recursive imports; it's there because the code is
short enough and tightly-coupled enough that I didn't see upside in
splitting any of it out to a separate
Rob Gaddi rgaddi@technologyhighland.invalid writes:
So, I'll take the app I'm working on right now as an example. I've got
348 lines in my __init__.py, and another 200 in another library.
Little baby program.
By “another library”, I think you mean “another module”. I'll assume
that in the
Ethan Furman et...@stoneleaf.us writes:
On 02/06/2015 02:56 PM, Ben Finney wrote:
It is a deliberate design decision that direct import of a module
makes that module blind to its location in the package hierarchy.
That's a design decision I deplore, because it makes something that
On 02/06/2015 06:56 PM, Steven D'Aprano wrote:
Dave Angel wrote:
And don't name any source code __main__.py,
That's incorrect.
Starting from Python 2.6, __main__.py is reserved for the application main
script in packages. That is, if you design your application as a package
(not a single
Rob Gaddi rgaddi@technologyhighland.invalid writes:
So I'm trying to wrap my head around packaging issues
Congratulations on tackling this. You will likely find the Python
Packaging User Guide URL:https://packaging.python.org/ helpful.
Also know that Python packaging was in a terrible state
Dave Angel wrote:
And don't name any source code __main__.py,
That's incorrect.
Starting from Python 2.6, __main__.py is reserved for the application main
script in packages. That is, if you design your application as a package
(not a single file) with this structure:
myapplication/
+--
11 matches
Mail list logo
