[Twisted-Python] twisted.python.dist as a public API

[Adi Roiban]

Hi,

Why is twisted.python.dist3.py a public module?

Are there any external projects which need to get the list of the modules
ported to Python3?

------------------

Why is twisted.python.dist a public module?

The docstring starts with `Don't use this outside of Twisted.' but why not
named it twisted.python._dist or twisted.python._setup to make it clear
that it is private ?

-------

I am trying to clean up the setup.py code as I feel that having the setup()
definition split between setup.py and dist.py is not ideal

----------

Can I rename twisted.python.dist and remove unused code from
twisted.python.dist without a deprecation dance?

--------------

The dedicated ticket is here https://twistedmatrix.com/trac/ticket/8622 and
is in the review queue

Regards,

[Glyph Lefkowitz]

Hi,
Why is twisted.python.dist3.py <http://twisted.python.dist3.py/> a public module?

Negligence on the part of a code reviewer :).

Are there any external projects which need to get the list of the modules ported to Python3?

No. This info should be private.

Why is twisted.python.dist a public module?

Similarly; this code was just accidentally made public without much thought. This is why twisted.python._release exists, and contains much more code;

The docstring starts with `Don't use this outside of Twisted.' but why not named it twisted.python._dist or twisted.python._setup to make it clear that it is private ?

Again; just a mistake.

I am trying to clean up the setup.py code as I feel that having the setup() definition split between setup.py and dist.py is not ideal

The purpose of putting stuff in dist.py was just to be able to unit test it. If you have some alternate strategy for testing, that might be better.

Can I rename twisted.python.dist and remove unused code from twisted.python.dist without a deprecation dance?

You always have to follow the compatibility process - if it's not a security bug, we would have to change the process first :-). But if you want to follow the exception path rather than the deprecation path (this message doesn't qualify, because the subject is incorrectly formatted) I certainly don't have any objection.

-glyph

[Adi Roiban]

On 7 August 2016 at 00:50, Glyph Lefkowitz <***@twistedmatrix.com> wrote:

[snip]

Post by Glyph Lefkowitz
You always have to follow the compatibility process - if it's not a
security bug, we would have to change the process first :-). But if you
want to follow the exception path rather than the deprecation path (this
message doesn't qualify, because the subject is incorrectly formatted) I
certainly don't have any objection.

As pointed by Craig in the PR, dist3.py is used by
https://github.com/habnabit/twisted-depgraph. I will revert the dist3
change.

With this email, I just wanted to get an initial feedback and try to
understand why we have code split between setup.py and dist.py

I will come back with an email following the compatibility process.

Thanks!

[Glyph Lefkowitz]

Post by Adi Roiban
[snip]
You always have to follow the compatibility process - if it's not a security bug, we would have to change the process first :-). But if you want to follow the exception path rather than the deprecation path (this message doesn't qualify, because the subject is incorrectly formatted) I certainly don't have any objection.
As pointed by Craig in the PR, dist3.py is used by https://github.com/habnabit/twisted-depgraph <https://github.com/habnabit/twisted-depgraph>. I will revert the dist3 change.

I should point out that the entire point of twisted-depgraph is to help Twisted developers - basically, you and Craig - understand the dependencies remaining and port more things to py3. So I'm pretty sure Aaron would not mind at all if he had to update it :). It's not really a user-facing application, just a core developer tool.

Post by Adi Roiban
With this email, I just wanted to get an initial feedback and try to understand why we have code split between setup.py and dist.py
I will come back with an email following the compatibility process.
Thanks!

No problem! I have a little tool that imports dist3 myself, and it is _super_ encouraging to see the percentages of ported code these days.

-g