5 ms·

Take a look at source code. The package hirarchy is not pythonic (use "libs" as top package is not a good idea).

by zbb 12y ago

binux 12y ago
agree
- redacted 12y ago
  What is the recommended way? (Serious question, I have larger projects that I would someday like to refactor into proper packages)
  - ngoldbaum 12y ago
    Because the name "libs" is now installed into the global module namespace. It's better to use a less generic name.
  - iamtew 12y ago
    There is also these guides that provide plenty of information on how packages work and best practices: https://packaging.python.org/en/latest/distributing.html https://packaging.python.org/en/latest/distributing.html https://github.com/pypa/sampleproject https://github.com/pypa/sampleproject
    - binux 12y ago
      I have "organize the code using a single top-level package".
paulhauggis 12y ago
Why isn't it a good idea? I have plenty of projects setup this way and it works well. It looks pretty well organized to me.
- vertex-four 12y ago
  The issue is that if you have two packages installed, and both use "libs" as their top-level package, they'll collide. Use "projectname.common" instead.
  - fmueller 12y ago
    This is not true, you can specify package directories in setup.py. See https://docs.python.org/2/distutils/setupscript.html#listing-whole-packages https://docs.python.org/2/distutils/setupscript.html#listing...
    - vertex-four 12y ago
      A package name != the actual name of the directory in the source tree. My point stands.
- deleted 12y ago
  [deleted]
huskyr 12y ago
Ah damned. the package hierarchy is not pythonic. That renders all the functionality of this package completely unusable. Come on people, don't be like this. It takes 5 seconds to rephrase a comment like this into something friendlier.
- binux 12y ago
  Yes, the scheduler, fetcher, processor is stand alone here, they are running in different process. But they are sharing some common libs. I haven't made a decision how to put them into a single package, and running together. Any advice or project that I can refer to?

Take a look at source code. The package hirarchy is not pythonic (use "libs" as top package is not a good idea).

by zbb 12y ago

Take a look at source code. The package hirarchy is not pythonic (use "libs" as top package is not a good idea).

binux 12y ago

agree

redacted 12y ago
What is the recommended way? (Serious question, I have larger projects that I would someday like to refactor into proper packages)
- ngoldbaum 12y ago
  Because the name "libs" is now installed into the global module namespace. It's better to use a less generic name.
- iamtew 12y ago
  There is also these guides that provide plenty of information on how packages work and best practices: https://packaging.python.org/en/latest/distributing.html https://packaging.python.org/en/latest/distributing.html https://github.com/pypa/sampleproject https://github.com/pypa/sampleproject
  - binux 12y ago
    I have "organize the code using a single top-level package".

paulhauggis 12y ago

Why isn't it a good idea? I have plenty of projects setup this way and it works well. It looks pretty well organized to me.

vertex-four 12y ago
The issue is that if you have two packages installed, and both use "libs" as their top-level package, they'll collide. Use "projectname.common" instead.
- fmueller 12y ago
  This is not true, you can specify package directories in setup.py. See https://docs.python.org/2/distutils/setupscript.html#listing-whole-packages https://docs.python.org/2/distutils/setupscript.html#listing...
  - vertex-four 12y ago
    A package name != the actual name of the directory in the source tree. My point stands.
deleted 12y ago
[deleted]

huskyr 12y ago

Ah damned. the package hierarchy is not pythonic. That renders all the functionality of this package completely unusable. Come on people, don't be like this. It takes 5 seconds to rephrase a comment like this into something friendlier.

binux 12y ago
Yes, the scheduler, fetcher, processor is stand alone here, they are running in different process. But they are sharing some common libs. I haven't made a decision how to put them into a single package, and running together. Any advice or project that I can refer to?