pydoctor is a Python API documentation generator. It is similar to dev-python/sphinx and dev-python/epydoc, but is performs a thorough static code analysis and supports zope.interface's declaration API. Homepage: http://pypi.python.org/pypi/pydoctor pydoctor is used to generate the API documentation of the Twisted project, which is a fairly large and major Python package. https://twistedmatrix.com/documents/current/api/twisted.html
Created attachment 337394 [details] pydoctor-0.5_beta1.ebuild My first attempt at an ebuild for pydoctor. It's based on the dev-python/sphinx ebuild. It works for me, but it may have issues. Any fixes and improvements are welcome.
> LICENSE="MIT/X11" Licenses are space separated as far as I know; there doesn't seem t be a X11 license, can you attach that license as well or is is this some sort of specialization of the MIT license (I doubt so)?
"MIT/X11" is what it says on http://pypi.python.org/pypi/pydoctor in the metadata section. I think "MIT/X11" in PyPI refers to "the form of the MIT licence that was/is used with X11". The actual LICENSE.txt looks like a slightly re-formulated MIT license.
Created attachment 337450 [details] pydoctor LICENSE.txt
testuser@archtester ~/improvise/dev-python/pydoctor $ ls /mnt/gen2/TmpDir/portage/dev-python/pydoctor-0.5_beta1/work/pydoctor-0.5b1//pydoctor//test/ importingfrompackage test_commandline.pyc test_model.pyc test_server.py __init__.py test_epydoc2stan.py test_nevowhtml.py test_server.pyc __init__.pyc test_epydoc2stan.pyc test_nevowhtml.pyc test_twistedmodel.py test_astbuilder.py test_formatting.py testpackages test_twistedmodel.pyc test_astbuilder.pyc test_formatting.pyc test_packages.py test_zopeinterface.py test_ast_pp.py test_liveobjectchecker.py test_packages.pyc test_zopeinterface.pyc test_ast_pp.pyc test_liveobjectchecker.pyc test_pickling.py test_commandline.py test_model.py test_pickling.pyc Step 1. A test folder beckons a src_test(). There are enough packages with untouched test suites as it is, (Precompiled .pyc files generally are not needed and cause trouble) Step2. Put a case to the python team lead that warrants its addition to portage, in wither order.
in either order that is
(In reply to comment #5) > > Step 1. A test folder beckons a src_test(). There are enough packages with > untouched test suites as it is, (Precompiled .pyc files generally are not > needed and cause trouble) Sorry, I should have mentioned that I am still a newbie ebuild author. I mainly put the ebuild here for more experienced people to take over. I suspect that src_test() refers to an ebuild function, but from your post I do not know what I should do there. > Step2. Put a case to the python team lead that warrants its addition to > portage, in wither order. How do I put a case to the python team lead, and who would that be?
Florian, consider it done. djc can you give the user a verdict on its suitability, then tidying up the ebuild will be fairly easy.
(In reply to comment #8) > Florian, consider it done. Thanks. I hope to provide higher quality drafts when I gain more experience.
Ian, please don't make it look like as if I decide what packages go in; I don't think that's the case. I've discussed this with Mike, and I think the policy should be that we want at least two (semi-independent) users on Bugzilla expressing interest before the python team will pick something up. This would be a criterion of "sufficient, not necessary" type. Other python team members, feel free to speak up (on the mailing list) if you disagree.
right, once we see that increase in demand, I'm happy to add it once a test phase is added. If you wish to see learn how that's done, you have the options of joining directly in gentoo-python irc, or via the sunrise project which supports users with new ebuilds.
I will say at this point maffblaster is looking a potential proxy maintianer of this package.
I will say at this point maffblaster is looking a potential proxy maintainer of this package.
I'll this thi
Fine, I'll take it. :P Ebuild coming shortly...
