零件层次结构的构建配方

发布于 2024-07-26 16:39:24 字数 869 浏览 4 评论 0原文

是否有一个 Python buildout 配方可以允许以下操作:

[buildout]
parts = group-of-parts

[group-of-parts]
recipe = what.can.i.use.for.this
parts = part-1 part-2

[part-1]
...

[part-2]
...

换句话说,我想要一个需要“parts”属性与“buildout”部分非常相似,因此我可以手动管理零件组的层次结构。

是的,我知道我可以这样做:

[buildout]
parts = group-of-parts

[group-of-parts]
recipe =
parts = ${part-1:recipe} ${part-2:recipe}

[part-1]
...

[part-2]
...

但是依赖于通过引用零件的属性来构建零件的副作用似乎有点晦涩。 我宁愿通过使用一个只允许列出零件本身的名称的配方来更明确。

当然,在扩展和覆盖时,它看起来更干净:

[groups-of-parts]
parts -= part-2

比:

[groups-of-parts]
parts -= ${part-2:recipe}

或者我的问题是我只是错过了关于构建如何工作的基本内容,或者只是忽略了文档中的一些内容,这使得这变得更加清晰。

不,我不想有一个扁平的层次结构,其中所有部件都列在“构建”部分的“部件”属性中。

Is there a Python buildout recipe which would allow the following:

[buildout]
parts = group-of-parts

[group-of-parts]
recipe = what.can.i.use.for.this
parts = part-1 part-2

[part-1]
...

[part-2]
...

In other words, I want a recipe which takes a 'parts' attribute much like 'buildout' section does so I can manually manage a hierarchy of groups of parts.

Yes, I know that I could do:

[buildout]
parts = group-of-parts

[group-of-parts]
recipe =
parts = ${part-1:recipe} ${part-2:recipe}

[part-1]
...

[part-2]
...

but relying on the side effect that the parts will be built by referencing an attribute of them seems a bit obscure. I would rather it be more explicit by using a recipe which would just allow the name of the part itself to be listed.

Certainly when extending and overriding, it looks a lot cleaner to say:

[groups-of-parts]
parts -= part-2

than:

[groups-of-parts]
parts -= ${part-2:recipe}

Or is my problem that I am just missing something fundamental about how buildout works, or just overlooking something in the documentation which makes this much cleaner.

And no I don't want to have a flat hierarchy where all parts are listed in the 'parts' attribute of the 'buildout' section.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

蔚蓝源自深海 2024-08-02 16:39:24

不,没有层次结构,当然你可以为其构建一个配方。

你为什么需要它? 这并不是说您最终会拥有数百个零件,因此很难跟踪它们......

No, there is no hierarchy, although you could build a recipe for it, of course.

Why do you want it? It's not like you end up with hundreds of parts so it's hard to keep track of them...

漆黑的白昼 2024-08-02 16:39:24

不久前,我写了一篇关于构建中的依赖解析的文章。 这不是你问题的答案,因为你想要的在我看来没有多大意义。 但您可能会深入了解依赖层次树解析构建的用途。

Some time ago I wrote an article on dependency resolution in buildout. Its not an answer to your question, because what you want does not make much sense in my opinion. But you may get an insights to dependency hierachy tree resolution buildout uses.

初心 2024-08-02 16:39:24

你可以这样做:

[buildout]
development-tools-parts =
    thing1
    thing2
software-parts =
    thing3
    thing4
parts =
    ${buildout:development-tools-parts}
    ${buildout:software-parts}

我对你的理解正确吗?

它之所以有效,是因为大多数构建配置语句只是列表。 您可以将其相互附加。

我有时使用它来扩展基本的构建配置(“base.cfg”)。 这将为您提供一个 ${buildout:common-parts} 您可以将其添加到零件列表中以获取其中的几个标准项目。 只是给你举个例子。

You can do this:

[buildout]
development-tools-parts =
    thing1
    thing2
software-parts =
    thing3
    thing4
parts =
    ${buildout:development-tools-parts}
    ${buildout:software-parts}

Did I understand you correctly?

It works because most of those buildout configuration statements are just lists. Which you can append to each other.

I used this sometimes for a basic builout config ("base.cfg") that I would extend from. This would give you a ${buildout:common-parts} you could add to your parts list to get a couple of standard items in there. Just to give you an example.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文