永远不再重塑 [英] Reinvent no more forever

问题描述

Howdy all，


在dirtSimple.org [0]上，PJE写道：


"为什么Python祝福如此多的重塑？因为它的重写成本通常比重用要便宜。 Python代码很容易写入，但很难依赖。您几乎必须：


1.限制自己使用合适包装的平台

系统，

2.捆绑全部你的依赖你的发行版，或

3.让你的用户自己做所有的工作


哎哟。难怪重写看起来更容易。


然后他继续谈论他自己的解决方案：PyPI，setuptools，

EasyInstall，等等更好依赖控制。他的结论是：


但是现在，我打算先把我的依赖关系

放在嘴边。我将永远不会捆绑，因为我累了

让他们与上游维护人员保持同步。我将
将我的单片包装拆成更小的项目，这样

的人可以使用PEAK的很酷的部分，而无需

安装任何东西但他们想要的部分。我会发现这个

的东西是否真的有效。从设置工具现在的位置开始，我将永远不再需要b $ b捆绑。


精致的情绪。这对PyPI来说意味着什么？那些想要不再重塑的我们应该怎样呢？继续？我们如何处理
处理在PyPI中的一些标准习语的广泛实施？


让我陷入这种困境很简单：我正在开发一个可能变得简单的

应用程序，我正在寻找可能有价值的
件在此申请之外。第一个吸引我注意的是
是一个Enum实现。


我现在有一个我的Enum实现的setuptools包。我应该将
提交给PyPI吗？


优点：


- 我可以声明对该包的依赖对于我需要这些功能的所有其他

套餐，而不是每次都捆绑它

。


- 其他人可以从中受益我的代码，而不是再次包含一个

Enum实现（本地化，或从菜谱中挑选）通过

简单的依赖声明。


- 代码有望得到改进和推广以及所有其他

从许多用户获得的软件中获益。


缺点：


- 扩散。当[1]其他人将

（不兼容，不同指定）的Enum实现放入

PyPI时协议是什么？


- 命名。提供Enum的包可以用多少种方式命名？

我更喜欢将其命名为Enum或enum，但为什么我的

是声称这个名字的人？


- 这只是一个非常简单的类型，单元测试。这真的是
证明一个PyPI包吗？


这对任何代码库都是通用的。但是自动

依赖问题意味着所有这些软件包以及该软件库之外的更多信息需要知道这些问题是如何解决的。


操作系统分销商有政策（到或多或少

严格程度）以确保这种质量控制。我对PyPI的理解是，没有这样的政策。


我很想跟随PJE的口头禅，但是如果它'这对一个人来说是好事，对于无数其他人来说这可能是个好消息。我们如何处理

？我们可以提前采取什么行动来防止

未来出现问题？

[0]< URL：http：//dirtsimple.org/2005/07/reinvent-没有更多forever.html>


[1]当然，有人已经有了。我更喜欢我的，因此

问题。


-

\我种了一些鸟种子。一只鸟出现了。现在我不知道|

` \喂它的原因。 - 史蒂芬赖特|

_o__）|

Ben Finney

Howdy all,

On dirtSimple.org[0], PJE wrote:

"Why is Python "blessed" with so much reinvention? Because it''s
often cheaper to rewrite than to reuse. Python code is easy to
write, but hard to depend on. You pretty much have to:

1. limit yourself to platforms with a suitable packaging
system,
2. bundle all your dependencies into your distribution, or
3. make your users do all the work themselves

Ouch. No wonder rewriting looks easier."

He then goes on to talk about his own solution: PyPI, setuptools,
EasyInstall, and so on for better dependency control. He concludes:

"But for right now, I plan to start by putting my dependencies
where my mouth is. I will bundle no more forever, for I am tired
of keeping them up-to-date with their upstream maintainers. I
shall rend my monolithic packages into smaller projects, so that
people can make use of cool parts of PEAK without having to
install anything but the part they want. I will find out if this
stuff really works. From where the setuptools now stand, I will
bundle no more forever."

Fine sentiments. What does this mean for PyPI though? How should those
of us who also want to "reinvent no more forever" proceed? How do we
deal with the rampant proliferation of a zillion implementations of
some standard idiom in PyPI?

The case that led me to this quandary is simple: I''m developing an
application that could become simple, and I''m on the lookout for
pieces that might be valuable outside this application. The first one
to catch my eye is an Enum implementation.

I now have a setuptools package of my Enum implementation. Should I
submit it to PyPI?

Advantages:

- I can declare a dependency on that package for all my other
packages that need such functionality, instead of bundling it
every time.

- Others can benefit from my code, instead of yet again including an
Enum implementation (home-grown, or picked from a cookbook) by a
simple dependency declaration.

- The code hopefully gets improved and generalised and all the other
benefits that accrue to software with many users.

Disadvantages:

- Proliferation. What''s the protocol when[1] someone else puts an
(incompatible, differently-specified) Enum implementation into
PyPI?

- Naming. How many ways can a package providing an Enum be named?
I''d prefer mine to be named "Enum" or "enum", but why should mine
be the one that claims that name?

- It''s just a pretty simple type, with unit tests. Does this really
justify a PyPI package?

This is common to any repository of code. But the "automatic
dependency" problem means that all those packages, and many more
outside that repository, need to know how those problems are resolved.

Operating system distributors have policies (to greater or lesser
degrees of strictness) to ensure this kind of quality control. My
understanding of PyPI is that there''s no such policy.

I''d love to follow the mantra PJE espouses, but if it''s good for one
person it''s probably good for countless others. How do we deal with
that? What actions can we take in advance to prevent problems in
future?
[0] <URL:http://dirtsimple.org/2005/07/reinvent-no-more-forever.html>

[1] Of course, someone already has. I prefer mine to theirs, hence the
question.

--
\ "I planted some bird seed. A bird came up. Now I don''t know |
`\ what to feed it." -- Steven Wright |
_o__) |
Ben Finney

推荐答案

Ben Finney写道：

Ben Finney wrote:

你好，


你好，

在dirtSimple.org [0]上，PJE写道：

为什么Python祝福如此多的重塑？因为重写通常比重用更便宜。 Python代码很容易编写，但很难依赖。您几乎必须：

1.限制自己使用合适的包装系统，
2.将所有依赖项捆绑到您的发行版中，或者



对于纯python模块我不认为这是一个大问题。

3.让你的用户自己完成所有的工作
哎哟。难怪重写看起来更容易。
[snip ..]
我现在有一个我的Enum实现的setuptools包。我应该将它提交给PyPI吗？

优点：

- 我可以声明对所有其他需要的包裹的依赖功能，而不是每次捆绑它。

- 其他人可以从我的代码中受益，而不是再次包括Enum实现（本土或从中挑选）简单的依赖声明。

- 希望代码得到改进和推广，以及许多用户为软件带来的所有其他好处。


这些都是非常令人信服的理由。

缺点：

- 扩散。当[1]其他人将
（不兼容，不同指定的）Enum实现放入
PyPI时，协议是什么？


那不应该''问题不仅仅是目前的情况。在

事实上，当setuptools系统变得更加成熟时，它应该更容易让人们发现现有的包装做了什么他们想要的b $ b - 而不是创建自己的。

- 命名。提供Enum的包可以用多少种方式命名？
我更喜欢将其命名为Enum。或enum，但为什么我的
是声称这个名字的人？


我认为先到先得这是唯一可行的方式

工作。

- 它只是一个非常简单的类型，有单元测试。这是否真的证明了PyPI包的合理性？


如果它以优雅的方式解决了一个常见问题，那么它会更好

分享。 :-)

这对任何代码库都是通用的。但是自动
依赖问题意味着所有这些软件包以及更多的软件包都需要知道这些问题是如何解决的。

操作系统分销商有政策（大致或小于等级）严格的）确保这种质量控制。我对PyPI的理解是没有这样的政策。

我很乐意遵循PJE的咒语，但是如果它对一个人有好处的话。 >对于无数其他人来说，这可能是好事。我们如何处理
那个？我们可以提前采取什么行动来防止未来出现问题？


难道没有设置工具*解决这些问题的系统*？它提供了

a方式来跟踪和自动安装依赖项 - 只要你有

正确的netowrk连接[1]和
的打包器
依赖项以与setuptools兼容的方式提供它们。


一切顺利，


模糊
http://www.voidspace.org.uk/python/index.shtml


[1] setuptools使用python代码访问互联网并安装

依赖项。 Python代码无法通过代理获取https URL，并且
根本无法使用SOCKS代理。这意味着对某些类型的互联网

conenctions（例如在公司防火墙后面）它不起作用。建设

pycurl进入setuptools的可选支持可能会解决这个问题。

[0]< URL：http：//dirtsimple.org /2005/07/reinvent-no-more-forever.html>

[1]当然，有人已经拥有。我更喜欢我的，因此
问题。

-
\我种了一些鸟种子。一只鸟出现了。现在我不知道了什么来喂它。 - Steven Wright |
_o__）|
Ben Finney

Howdy all,

Hello,
On dirtSimple.org[0], PJE wrote:

"Why is Python "blessed" with so much reinvention? Because it''s
often cheaper to rewrite than to reuse. Python code is easy to
write, but hard to depend on. You pretty much have to:

1. limit yourself to platforms with a suitable packaging
system,
2. bundle all your dependencies into your distribution, or

For pure python modules I don''t find this to be a big problem.
3. make your users do all the work themselves

Ouch. No wonder rewriting looks easier."
[snip..]
I now have a setuptools package of my Enum implementation. Should I
submit it to PyPI?

Advantages:

- I can declare a dependency on that package for all my other
packages that need such functionality, instead of bundling it
every time.

- Others can benefit from my code, instead of yet again including an
Enum implementation (home-grown, or picked from a cookbook) by a
simple dependency declaration.

- The code hopefully gets improved and generalised and all the other
benefits that accrue to software with many users.

These are all very compelling reasons.
Disadvantages:

- Proliferation. What''s the protocol when[1] someone else puts an
(incompatible, differently-specified) Enum implementation into
PyPI?

That shouldn''t be any more of a problem than the current situation. In
fact as the setuptools system becomes more established then it should
be easier for people to discover that an existing package does what
they want - rather than creating their own.
- Naming. How many ways can a package providing an Enum be named?
I''d prefer mine to be named "Enum" or "enum", but why should mine
be the one that claims that name?

I think "first come - first served" is the only possible way this can
work.
- It''s just a pretty simple type, with unit tests. Does this really
justify a PyPI package?

If it solves a common problem in an elegant way, then it''s better
shared. :-)
This is common to any repository of code. But the "automatic
dependency" problem means that all those packages, and many more
outside that repository, need to know how those problems are resolved.

Operating system distributors have policies (to greater or lesser
degrees of strictness) to ensure this kind of quality control. My
understanding of PyPI is that there''s no such policy.

I''d love to follow the mantra PJE espouses, but if it''s good for one
person it''s probably good for countless others. How do we deal with
that? What actions can we take in advance to prevent problems in
future?

Isn''t setuptools *the system* that addresses these issues ? It provides
a way to track and auto-install dependencies - so long as you have the
right kind of netowrk connection [1] and the packager of the
dependencies provides them in a way compatible with setuptools.

All the best,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

[1] setuptools uses python code to access the internet and install
dependencies. Python code can''t fetch https URLs through a proxy and
can''t use a SOCKS proxy at all. That means with some kinds of internet
conenctions (e.g. behind company firewalls) it doesn''t work. Building
optional support for pycurl into setuptools could possibly resolve
this.

[0] <URL:http://dirtsimple.org/2005/07/reinvent-no-more-forever.html>

[1] Of course, someone already has. I prefer mine to theirs, hence the
question.

--
\ "I planted some bird seed. A bird came up. Now I don''t know |
`\ what to feed it." -- Steven Wright |
_o__) |
Ben Finney

Ben Finney写道：

Ben Finney wrote:

你好，


你好，

在dirtSimple.org [0]上，PJE写道：

为什么是Python祝福如此多的重塑？因为重写通常比重用更便宜。 Python代码很容易编写，但很难依赖。您几乎必须：

1.限制自己使用合适的包装系统，
2.将所有依赖项捆绑到您的发行版中，或者



对于纯python模块我不认为这是一个大问题。

3.让你的用户自己完成所有的工作
哎哟。难怪重写看起来更容易。
[snip ..]
我现在有一个我的Enum实现的setuptools包。我应该将它提交给PyPI吗？

优点：

- 我可以声明对所有其他需要的包裹的依赖功能，而不是每次捆绑它。

- 其他人可以从我的代码中受益，而不是再次包括Enum实现（本土或从中挑选）简单的依赖声明。

- 希望代码得到改进和推广，以及许多用户为软件带来的所有其他好处。


这些都是非常令人信服的理由。

缺点：

- 扩散。当[1]其他人将
（不兼容，不同指定的）Enum实现放入
PyPI时，协议是什么？


那不应该''问题不仅仅是目前的情况。在

事实上，当setuptools系统变得更加成熟时，它应该更容易让人们发现现有的包装做了什么他们想要的b $ b - 而不是创建自己的。

- 命名。提供Enum的包可以用多少种方式命名？
我更喜欢将其命名为Enum。或enum，但为什么我的
是声称这个名字的人？


我认为先到先得这是唯一可行的方式

工作。

- 它只是一个非常简单的类型，有单元测试。这是否真的证明了PyPI包的合理性？


如果它以优雅的方式解决了一个常见问题，那么它会更好

分享。 :-)

这对任何代码库都是通用的。但是自动
依赖问题意味着所有这些软件包以及更多的软件包都需要知道这些问题是如何解决的。

操作系统分销商有政策（大致或小于等级）严格的）确保这种质量控制。我对PyPI的理解是没有这样的政策。

我很乐意遵循PJE的咒语，但是如果它对一个人有好处的话。 >对于无数其他人来说，这可能是好事。我们如何处理
那个？我们可以提前采取什么行动来防止未来出现问题？


难道没有设置工具*解决这些问题的系统*？它提供了

a方式来跟踪和自动安装依赖项 - 只要你有

正确的netowrk连接[1]和
的打包器
依赖项以与setuptools兼容的方式提供它们。


一切顺利，


模糊
http://www.voidspace.org.uk/python/index.shtml


[1] setuptools使用python代码访问互联网并安装

依赖项。 Python代码无法通过代理获取https URL，并且
根本无法使用SOCKS代理。这意味着对某些类型的互联网

conenctions（例如在公司防火墙后面）它不起作用。建设

pycurl进入setuptools的可选支持可能会解决这个问题。

[0]< URL：http：//dirtsimple.org /2005/07/reinvent-no-more-forever.html>

[1]当然，有人已经拥有。我更喜欢我的，因此
问题。

-
\我种了一些鸟种子。一只鸟出现了。现在我不知道了什么来喂它。 - Steven Wright |
_o__）|
Ben Finney

Howdy all,

Hello,
On dirtSimple.org[0], PJE wrote:

"Why is Python "blessed" with so much reinvention? Because it''s
often cheaper to rewrite than to reuse. Python code is easy to
write, but hard to depend on. You pretty much have to:

1. limit yourself to platforms with a suitable packaging
system,
2. bundle all your dependencies into your distribution, or

For pure python modules I don''t find this to be a big problem.
3. make your users do all the work themselves

Ouch. No wonder rewriting looks easier."
[snip..]
I now have a setuptools package of my Enum implementation. Should I
submit it to PyPI?

Advantages:

- I can declare a dependency on that package for all my other
packages that need such functionality, instead of bundling it
every time.

- Others can benefit from my code, instead of yet again including an
Enum implementation (home-grown, or picked from a cookbook) by a
simple dependency declaration.

- The code hopefully gets improved and generalised and all the other
benefits that accrue to software with many users.

These are all very compelling reasons.
Disadvantages:

- Proliferation. What''s the protocol when[1] someone else puts an
(incompatible, differently-specified) Enum implementation into
PyPI?

That shouldn''t be any more of a problem than the current situation. In
fact as the setuptools system becomes more established then it should
be easier for people to discover that an existing package does what
they want - rather than creating their own.
- Naming. How many ways can a package providing an Enum be named?
I''d prefer mine to be named "Enum" or "enum", but why should mine
be the one that claims that name?

I think "first come - first served" is the only possible way this can
work.
- It''s just a pretty simple type, with unit tests. Does this really
justify a PyPI package?

If it solves a common problem in an elegant way, then it''s better
shared. :-)
This is common to any repository of code. But the "automatic
dependency" problem means that all those packages, and many more
outside that repository, need to know how those problems are resolved.

Operating system distributors have policies (to greater or lesser
degrees of strictness) to ensure this kind of quality control. My
understanding of PyPI is that there''s no such policy.

I''d love to follow the mantra PJE espouses, but if it''s good for one
person it''s probably good for countless others. How do we deal with
that? What actions can we take in advance to prevent problems in
future?

Isn''t setuptools *the system* that addresses these issues ? It provides
a way to track and auto-install dependencies - so long as you have the
right kind of netowrk connection [1] and the packager of the
dependencies provides them in a way compatible with setuptools.

All the best,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

[1] setuptools uses python code to access the internet and install
dependencies. Python code can''t fetch https URLs through a proxy and
can''t use a SOCKS proxy at all. That means with some kinds of internet
conenctions (e.g. behind company firewalls) it doesn''t work. Building
optional support for pycurl into setuptools could possibly resolve
this.

[0] <URL:http://dirtsimple.org/2005/07/reinvent-no-more-forever.html>

[1] Of course, someone already has. I prefer mine to theirs, hence the
question.

--
\ "I planted some bird seed. A bird came up. Now I don''t know |
`\ what to feed it." -- Steven Wright |
_o__) |
Ben Finney

Fuzzyman< fu ***** *@gmail.com>写道：

Fuzzyman <fu******@gmail.com> wrote:

Ben Finney写道：

Ben Finney wrote:

在dirtSimple.org [0]上，PJE写道：

[...] Python代码很简单写，但很难依靠。您几乎必须：

1.将自己限制在具有合适包装系统的平台上，
2.将所有依赖项捆绑到您的发行版中，或者

On dirtSimple.org[0], PJE wrote:

[...] Python code is easy to write, but hard to depend on. You
pretty much have to:

1. limit yourself to platforms with a suitable packaging
system,
2. bundle all your dependencies into your distribution, or

对于纯python模块我不觉得这是一个大问题。

For pure python modules I don''t find this to be a big problem.

这个问题不是是否是Python;问题是代码库的复杂性。一个简单的应用程序依赖于来自五个不同的非标准软件包的
基础架构变成了一个分配的混乱，它被困在其外围的代码中

自己的目的，并且不能从这些软件包的新版本中受益。

The problem isn''t whether it''s Python or not; the problem is the
complexity of the code base. A simple application that depends on
infrastructure from five different non-standard packages becomes a
right mess to distribute, is stuck with code that is peripheral to its
own purpose, and can''t benefit from new versions of those packages.

[通过PyPI分发一个简单的软件包]
- 扩散。当[1]其他人将（不兼容，不同指定的）Enum实现放入PyPI时，协议是什么？

[distributing a simple package via PyPI]

Disadvantages:

- Proliferation. What''s the protocol when[1] someone else puts
an (incompatible, differently-specified) Enum implementation
into PyPI?

那不应该''比现在的情况还要严重。
事实上，随着setuptools系统变得更加成熟，那么人们应该更容易发现现有的包裹做了他们想要的东西 - 而不是创建自己的。

That shouldn''t be any more of a problem than the current situation.
In fact as the setuptools system becomes more established then it
should be easier for people to discover that an existing package
does what they want - rather than creating their own.

我将所有现有的公共源代码存储库作为证据

反对您的预测。令人沮丧地重新发明轮子很常见，并且依赖工具不会阻止它。

I hold up all existing public source code repositories as evidence
against your prediction. Reinventing the wheel is distressingly
common, and a dependency tool isn''t going to stop that.

- 命名。提供Enum的包可以用多少种方式命名？我希望我的名字叫Enum。或者enum，但是为什么
应该是那个声称这个名字的人？

- Naming. How many ways can a package providing an Enum be
named? I''d prefer mine to be named "Enum" or "enum", but why
should mine be the one that claims that name?

我认为先到先得。这是唯一可行的方式。

I think "first come - first served" is the only possible way this
can work.

也许是这样。

Perhaps so.

- 它只是一个非常简单的类型，有单元测试。这是否真的证明了PyPI包的合理性？

- It''s just a pretty simple type, with unit tests. Does this
really justify a PyPI package?

如果它以优雅的方式解决了一个常见的问题，那么它会更好地共享。 ： - ）

If it solves a common problem in an elegant way, then it''s better
shared. :-)

当然。但问题是，PyPI是否可以这样做？

Sure. But the question was, is PyPI the place to do so?

这对任何代码库都是通用的。但是自动
依赖问题意味着所有这些软件包以及更多的软件包都需要知道这些问题是如何解决的。

操作系统分销商有政策（要么更大或更小<严格程度）确保这种质量控制。我对PyPI的理解是没有这样的政策。

This is common to any repository of code. But the "automatic
dependency" problem means that all those packages, and many more
outside that repository, need to know how those problems are
resolved.

Operating system distributors have policies (to greater or lesser
degrees of strictness) to ensure this kind of quality control. My
understanding of PyPI is that there''s no such policy.

是不是设置工具*解决这些问题的系统*？它提供了一种跟踪和自动安装依赖关系的方法[...]

Isn''t setuptools *the system* that addresses these issues ? It
provides a way to track and auto-install dependencies [...]

不，setuptools只是包本身的答案;我描述的

问题是包存储库固有的。


setuptools依赖模型依赖于

包的可靠性库。不仅在可用性方面，而且在包装的质量和功能方面还有

条款。


-

我去了博物馆，在那里他们拥有所有其他博物馆中的雕像。所有其他博物馆的雕像都是这样的。 - 史蒂文|

_o__）赖特|

Ben Finney

No, setuptools is only the answer for the packages themselves; the
problems I describe are inherent to the package repository.

The setuptools dependency model rests on the reliability of the
package repository. Not only in terms of availability but also in
terms of the quality and functionality of the package set.

--
\ "I went to the museum where they had all the heads and arms |
`\ from the statues that are in all the other museums." -- Steven |
_o__) Wright |
Ben Finney

这篇关于永远不再重塑的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！