Make the test suite working again!
Please, package tests as well
I really hope you were not asking to pollute everyone's download form PyPI. The _test directory is included in the automatically generated tarball (I just checked), but of course not in the package PyPI https://sourceforge.net/projects/ruamel-dl-tagged-releases/files/ Those files there are generated from a clean check out of the (tagged) source code.
Please, package tests as well
NameError: name 'Str' is not defined
I guess nobody (including me) uses the tar.gz instead of the wheel. Please close this if 0.8.3 solves this issue
update setup.py for 3.8 ast imports
Added tag 0.8.3 for changeset 841aac73f741
Docs say Deprecated since version 3.8: Old classes ast.Num, ast.Str, ast.Bytes, ast.NameConstant and ast.Ellipsis are still available, but they will be removed in future Python releases. Changing the import from _ast to ast might fix it, but only temporarily until a future release.
NameError: name 'Str' is not defined
sync setup.py with wheel info
- python 3.4
json __init__.py
- new setup
include version stuff so it can be upgraded
intermediate version 0.5.2 fixed on ruamel.base 0.3
license
better message when running tests without installing package
copyright and pep8 updates
- removed remnants of creating __init__.py
added sub_parser, global_option, global_only_option, create_argument_parser
- added license
description updated
added documentation and example programs
initial version
add SmartFormatter and tests
- update failing test on py26
initial ProgramBase
should not decorate __init__ if a class is going to be subclassed
added upload stuff
- include argparse for 2.6 (tox would work because dependency on
--help-all added
remove creation/check __init__.py
corrected typos and url based on feedback from Sess (leycec@gmail.com)
Added set_default_subparser code as extra method for ArgumentParser.
enable --version combined with default_sub_parser
sub sub parsers added
update setup, remove transition dependency on ruamel.yaml
Added tag 0.7.1 for changeset dc56189a99f2
glob matchin on plugin relative to module
Added tag 0.7.1 for changeset dc56189a99f2
Added tag 0.8.1 for changeset f79635fbec9b
Added tag 0.8.0 for changeset 3bd989d80f6e
status set to invalid I don't see any advantage in being able to "handle options from files" for the default subparser (if set) or any other subparser. If you define options in a file instead of defining them in the source, how would the program know what to do if, on invocation, such an option is specified on the command line. I have no idea what you are proposing here and why this should have major priority. (originally posted on 2017-05-04 at 18:02:53)