From the release notes: The installation process was modified: - Python 3 is now supported. This required new installation mechanics, and a Python pre-processor written for the circumstance (named pppp). - Pymacs now installs a single Python file instead of a Python module. This does not affect users — except maybe a few who chose to depend on undocumented internals. The specifications are pretty stable. A few additions occurred: - Variable pymacs-python-command may select which Python interpreter to use. - A pymacs-auto-restart variable lets the user decide what to do if the Pymacs helper aborts. - The Let class got a pops method which pops everything in a single call. - A new API function pymacs-autoload serves lazy imports. There also are miscellaneous changes: - Some errors have been corrected, both in the code and in the manual. - The Emacs Lisp source has been massaged so to become uploadable in ELPA’s (Emacs Lisp Packages Archives). XEmacs support seems to be broken, and Jython 2.2 support does not work yet. As I am not much of a user of either, this is kept on ice currently. Interested collaborators and testers, contact me if you feel like pushing in these areas! Nice thanks to Pymacs contributors. It was much fun working with you all!
pymacs-0.25 committed to CVS. Please test. For the time being, I've disabled Python 3 because of syntax errors.
Sorry for my very late response. :( Pymacs supports Python2 and Python3 through fixing up the sources during the compile phase. The current ebuild runs that preparation w/ the default python interpreter (which could be Python3) and runs the normal build with the specified Python version. Thus: You can easily end up with a Python3 fixed version that gets installed for Python2. I'll attach a patch that fixes this. I've left Python3 support disabled for now as well, as I had no time to look into the errors.
Created attachment 339572 [details] prepare sources for each python implementation
(In reply to comment #3) > Created attachment 339572 [details] > prepare sources for each python implementation you overwrite distutils-r1_python_prepare_all, because you do not call distutils-r1_src_prepare in src_prepare also: python_configure() is probably the better place to put "make PYSETUP=: PYTHON=${EPYTHON}"
example: a) src_configure() => our ebuild phase function (distutils-r1 exports distutils-r1_src_prepare() for us here which calls b) and c)) b) python_prepare() => run for each implementations (a no-op here) c) python_prepare_all() => run for all, as in: once (not a no-op) when you define src_prepare(), you want to call distutils-r1_src_prepare() to ensure that b) and c) are called as well if you define python_prepare_all() you can/should call distutils-r1_python_prepare_all() inside that function, unless you really want to overwrite it all when you define python_prepare() you could also run distutils-r1_python_prepare() inside that function, but since it's a no-op anyway, it does not make sense mind that this is different for distutils-r1_python_install() which is NOT a no-op I hope I was able to confuse you.
s/a) src_configure/a) src_prepare/
I think that the following patch should do the job: -python_configure_all() { +python_configure() { # pre-process the files but don't run distutils - emake PYSETUP=: + emake PYSETUP=: PYTHON=${EPYTHON} }
Oh, well... Pymacs wins the 'worst Python hack' contest for this year... Someone should point them that: a) maintaining such a large conditional blocks will soon result in inconsistent behavior between Python impls, b) they don't need to invent a preprocessor to use conditional blocks. They can just put them into the module... I'd rather see all those 'if's than those random blank lines. (In reply to comment #7) > I think that the following patch should do the job: > > -python_configure_all() { > +python_configure() { > # pre-process the files but don't run distutils > - emake PYSETUP=: > + emake PYSETUP=: PYTHON=${EPYTHON} > } Nope. This writes to source directory, so py2 version will overwrite py3 before compilation starts. This thing requires duplicating sources. In order to enable that, you either need to set DISTUTILS_IN_SOURCE_BUILD=1 or use python_prepare(). You also need to make sure python_copy_sources is called before any of distutils-r1 phases. You could do that implicitly by calling distutils-r1_src_prepare but it would collide with elisp thingie (duplicate epatch_user, at least). You could hack that over but I'm not really convinced it's worth the effort. So I'd just use whichever phase suits you better, set DISTUTILS_IN_SOURCE_BUILD=1 if necessary and call python_copy_sources manually in src_prepare().
Created attachment 340568 [details] pymacs-0.25.ebuild I've attached the current status of the ebuild. Thanks to mgorny for his help with the intricacies of python eclasses. It's not committed yet, because (according to mgorny) it conflicts with some eclass changes that are expected within the next days. Stay tuned.
(In reply to comment #9) > Created attachment 340568 [details] > pymacs-0.25.ebuild Committed with some minor changes as pymacs-0.25-r1.
