[issue15403] Refactor package creation support code into a common location

[STINNER Victor]

STINNER Victor  added the comment:

This issue is 7 years old and has patches: it is no newcomer friendly, I remove 
the "easy" keyword.

--
keywords:  -easy
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Nick Coghlan]

Changes by Nick Coghlan ncogh...@gmail.com:


--
assignee: ncoghlan - 

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Nick Coghlan]

Nick Coghlan added the comment:

I took a look at this last night, and found the combination of moving stuff 
around *and* refactoring it at the same time was too hard to review.

So, once the PEP 451 changes for runpy are done, I think it would make more 
sense to tackle this as at least three patches:

1. Do the refactoring *within* test_runpy to make the helper API a bit cleaner 
(this should also use types.SimpleNamespace where appropriate rather than a 
custom alternative)

2. Move the helper API out to a documented test.support.package_helper module 
without altering the test.support API

3+. Refactor other test modules to use the now shared API (there may be some 
pkg related functionality to move out of script_helper as well).

--
dependencies: +Rename and document test.script_helper as 
test.support.script_helper, Update runpy for PEP 451

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Nick Coghlan]

Nick Coghlan added the comment:

As noted in #18576 and #18578, I'd like for these relocation patches to include 
the addition of documentation for the submodule in Doc/library/test.rst

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Nick Coghlan]

Nick Coghlan added the comment:

Also, now that test.support is a subpackage, the helper should be a submodule 
of that (test.support.package_helper) rather than directly in the test 
directory.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Indra Talip]

Indra Talip added the comment:

updated patch to apply on top of patch from issue15494

--
nosy: +italip
Added file: http://bugs.python.org/file30870/issue-15403-3.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Eric Snow]

Changes by Eric Snow ericsnowcurren...@gmail.com:


--
nosy: +eric.snow

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek added the comment:

Attaching an updated patch.  Changes include:

1. Cleans up and expands support API to include creating nested directory 
structures (for use in the filecmp tests, for example).
2. Adds unit tests for the full API (similar to test_support.py).
3. Refactors test_filecmp and test_import to use the support code, in addition 
to test_runpy and test_cmd_line_script. We can remove some of these 
refactorings if you think it does not add much at this point.
4. Puts changes in package_helper.py for now (until issue 15494 is done). I 
didn't put them in script_helper.py to avoid creating a circular dependency.

--
Added file: http://bugs.python.org/file26670/issue-15403-2.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Nick Coghlan]

Changes by Nick Coghlan ncogh...@gmail.com:


--
dependencies: +Move test/support.py into a test.support subpackage

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek added the comment:

Lib/test/test_import.py also contains test code that would benefit from this 
(see for example issue 15425).  (Though not all files need to be refactored in 
a single issue.)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Antoine Pitrou]

Antoine Pitrou added the comment:

Please let's not have something called test.supportlib in addition to 
test.support. If test.support grows too large we can turn it into a package.

--
nosy: +pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek added the comment:

I feel like it is already too large (it is over 1750 lines), and I did not want 
to create a third sibling test support module (there is also 
test/script_helper.py that overlaps with test.support).  Do you think that the 
community would be open to refactoring test.support into a package for Python 
3.3?  This was meant to assist in increasing test coverage for Python 3.3 bugs.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Antoine Pitrou]

Antoine Pitrou added the comment:

 I feel like it is already too large (it is over 1750 lines), and I did
 not want to create a third sibling test support module (there is also
 test/script_helper.py that overlaps with test.support).  Do you think
 that the community would be open to refactoring test.support into a
 package for Python 3.3?  This was meant to assist in increasing test
 coverage for Python 3.3 bugs.

That's too late for 3.3, IMO. Whether or not test.support is too large
is a matter of taste (we have larger files in the stdlib; what makes
test.support annoying to work with is that it's a hodge-podge of utility
functions with little care for consistency). Unless we can clearly
separate it in thematic areas, making it a package would only make
finding stuff more difficult.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek added the comment:

At this point, would you advise me to add even more to the existing hodge 
podge, or to create a third sibling test support module?  My patch adds closely 
related test support functionality.

Incidentally, this discussion relates to the point I was getting at in the 
python-dev thread in the past couple days about how restrictions on refactoring 
test support code for maintenance releases can affect the quality of our test 
code.  I am still struggling with how to approach that.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Antoine Pitrou]

Antoine Pitrou added the comment:

I don't mind refactoring test support routines in maintenance release. I
said it was too late for 3.3 because the beta period is closing; but it
could be fine for 3.3.1 ;)

As for the way forward, I see three possibilites:
1) put everying in test.support, as a single module (that includes
folding script_helper into it)
2) make test.support a package of thematic modules
3) refactor test.support into a variety of independent modules
(script_helper, import_helper, socket_helper, etc.); a small
test.support providing fundamental features such as TESTFN could remain

My personal preference would be for 1) or 3). But whatever we choose, we
should do it consistently. Having a large test.support + a supportlib
package + some independent helpers is not a good idea.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek added the comment:

Thanks for your thoughts.  For the purposes of this patch, I will change to 
putting the new support functionality in test.support.  Going forward, if we 
could do some of the refactoring for 3.3.1, that would be great. :)

I worry that the third option may make things worse because it would become 
less obvious where all of the different test support functionality is located.

Are you opposed to (2), or is it simply less favorable?  The transition to (2) 
could be a gradual one beginning with two or even one module inside the package.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Antoine Pitrou]

Antoine Pitrou added the comment:

 Are you opposed to (2), or is it simply less favorable?

Less favorable, because it produces longer import strings
(test.support.some_helper instead of test.some_helper).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek added the comment:

 Less favorable, because it produces longer import strings
(test.support.some_helper instead of test.some_helper).

This can be addressed by exposing the API in __init__.py though (as does, say, 
the unittest package), no?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le dimanche 29 juillet 2012 à 17:00 +, Chris Jerdonek a écrit :
 Chris Jerdonek added the comment:
 
  Less favorable, because it produces longer import strings
 (test.support.some_helper instead of test.some_helper).
 
 This can be addressed by exposing the API in __init__.py though (as
 does, say, the unittest package), no?

Yes, that's right.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Nick Coghlan]

Nick Coghlan added the comment:

Discoverability is definitely a problem - part of that is a docs issue, since 
test.support is currently the only one mentioned in the prose docs.

One advantage to moving to a support subpackage is that we can lose the 
helper suffix from the names, while still allowing thematic divisions.

So, for example, we could have

# support.py - support/__init__.py
import test.support
# script_helper.py - support/scripts.py
import test.support.scripts
# Other possible additions
import test.support.imports
import test.support.network

Even without updating the prose docs, this would help discoverability a lot by 
having a much smaller directory listing to scan for useful support code. At the 
moment the general purpose helper modules are mixed in with the tests

I agree with Antoine that we're probably better off handling this as a refactor 
post-release at this point, though. I'd hoped to have the time to devote to it 
beforehand, but there's user facing stuff that's higher priority right now.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek added the comment:

Sounds good.  Later today I will create an issue to move test/support.py into a 
test.support subpackage post-release.

We can continue the discussion of how to organize it there.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek added the comment:

 Later today I will create an issue to move test/support.py into a 
 test.support subpackage post-release.

I created issue 15494 for this.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek chris.jerdo...@gmail.com added the comment:

It occurs to me that the filecmp/dircmp tests in Lib/test/test_filecmp.py would 
also benefit from code like this (i.e. being able to create a nested directory 
of files in one or two lines).  And perhaps elsewhere in the tests.

This is an argument for slightly generalizing the test support API in the 
uploaded patch from creating modules/packages to creating files/directories.  A 
convenience wrapper for packages could still be included that includes an 
__init__.py in the calls to the underlying directory code.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Nick Coghlan]

Changes by Nick Coghlan ncogh...@gmail.com:


--
assignee:  - ncoghlan

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Éric Araujo]

Changes by Éric Araujo mer...@netwok.org:


--
nosy: +eric.araujo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

New submission from Chris Jerdonek chris.jerdo...@gmail.com:

This issue addresses the file creation portion of issue 15376, which is to 
refactor the walk_package support code in test_runpy into a common location.

--
components: Tests
keywords: easy
messages: 165910
nosy: cjerdonek
priority: normal
severity: normal
stage: needs patch
status: open
title: Refactor package creation support code into a common location
versions: Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Changes by Chris Jerdonek chris.jerdo...@gmail.com:


--
nosy: +ncoghlan

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek chris.jerdo...@gmail.com added the comment:

Attaching patch.

--
keywords: +patch
Added file: http://bugs.python.org/file26447/issue-15403-1.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com