使用共享包部署 python 应用程序
我正在考虑如何安排一个已部署的 python 应用程序，该应用程序将在 /usr/bin/ 中具有一个
- 中实现的功能提供 CLI
- 可执行脚本，该脚本将为安装在当前 site-packages 目录所在位置的库
。 现在，目前，我的源代码中有以下目录结构：
foo.py
foo/
__init__.py
...
我认为这不是最好的方法。 在开发过程中，一切都按预期工作，但是在部署时，foo.py 中的“from foo import FooObject”代码似乎试图导入 foo.py 本身，这不是我正在寻找的行为。
那么问题是，协调这种情况的标准做法是什么？ 我能想到的一件事是，在安装时，将 foo.py 重命名为 foo，这会阻止它导入自身，但这看起来相当尴尬......
我想问题的另一部分是它是一个命名挑战。 也许将可执行脚本称为 foo-bin.py？
I'm thinking how to arrange a deployed python application which will have a
- Executable script located in /usr/bin/ which will provide a CLI to functionality implemented in
- A library installed to wherever the current site-packages directory is.
Now, currently, I have the following directory structure in my sources:
foo.py
foo/
__init__.py
...
which I guess is not the best way to do things. During development, everything works as expected, however when deployed, the "from foo import FooObject" code in foo.py seemingly attempts to import foo.py itself, which is not the behaviour I'm looking for.
So the question is what is the standard practice of orchestrating situations like this? One of the things I could think of is, when installing, rename foo.py to just foo, which stops it from importing itself, but that seems rather awkward...
Another part of the problem, I suppose, is that it's a naming challenge. Perhaps call the executable script foo-bin.py?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这篇文章非常好，并向您展示了一种很好的方法。 Do 列表中的第二项回答了您的问题。
无耻的复制粘贴：
This article is pretty good, and shows you a good way to do it. The second item from the Do list answers your question.
shameless copy paste:
Distutils 支持安装模块、包和脚本。 如果您创建一个 distutils
setup.py，它将foo作为包引用，将foo.py作为脚本引用，则foo. py应安装到/usr/local/bin或目标操作系统上任何适当的脚本安装路径，并且foo包应安装到site_packages目录。Distutils supports installing modules, packages, and scripts. If you create a distutils
setup.pywhich refers tofooas a package andfoo.pyas a script, thenfoo.pyshould get installed to/usr/local/binor whatever the appropriate script install path is on the target OS, and thefoopackage should get installed to thesite_packagesdirectory.您应该仅调用可执行文件
foo，而不是foo.py，然后尝试导入 foo 将不会使用它。至于正确命名：这很难抽象地回答； 我们需要知道它的具体作用。 例如，如果它进行配置和控制，则将其称为 -config 或 ctl 可能是合适的。 如果它是库的 shell API，则它应该与库具有相同的名称。
You should call the executable just
foo, notfoo.py, then attempts to import foo will not use it.As for naming it properly: this is difficult to answer in the abstract; we would need to know what specifically it does. For example, if it configures and controls, calling it -config or ctl might be appropriate. If it is a shell API for the library, it should have the same name as the library.
你的 CLI 模块是一回事，支持它的包是另一回事。 不要将模块
foo（在文件foo.py中）和包foo（在目录foo 中）的名称混淆与文件__init__.py）。您有两个名为
foo的东西：一个模块和一个包。 您还想将foo命名为什么？ 一类？ 一个函数？ 一个变量？为 foo 模块或 foo 包选择一个独特的名称。 例如，
foolib是一个流行的包名称。Your CLI module is one thing, the package that supports it is another thing. Don't confuse the names withe module
foo(in a filefoo.py) and the packagefoo(in a directoryfoowith a file__init__.py).You have two things named
foo: a module and a package. What else do you want to namefoo? A class? A function? A variable?Pick a distinctive name for the foo module or the foo package.
foolib, for example, is a popular package name.