[WIP] Port Python extensions to Python 3 #145
Conversation
Replace os.system with subprocess.call
nemo-compare.pot now reflects the actual translation strings. Existing translations were updated as well. Note that the copyright information from po files were incompatible with the GPL and hence removed. Also, reference information in po files are now relative to the top directory of the application as recommended[1][2] by GNU gettext. In particular, references now start with "src/". [1] https://www.gnu.org/software/gettext/manual/gettext.html#C-Sources-Context [2] https://www.gnu.org/software/gettext/manual/gettext.html#po_002fPOTFILES_002ein
The %-style substitutions allow fast combining of a fixed string with
variable content. So
"Compare to: " + other
changed to
"Compare to: %s" % other
Unlike concatenating, substituations account for flexible insertions and
can thus be helpful for more natural descriptions in some languages.
Moreover, RTL translations become possible.
|
@clem rabbitvcs provides the nemo extension https://github.com/rabbitvcs/rabbitvcs/commits/master rabbitvcs upstream seems pretty dead and bug riddled. P.S I wouldn't be bothered by it's complete removal. |
|
@clefebvre The problem is that the old Python 2 scripts won't work with a *something= go back to current Python 2 state, apply changes only to nemo-python, then fix all 2to3-related bugs, test if all extensions work as expected, then fix build scripts (I updated a lot of them). At that state everything should work like it does now besides running on Py3 instead of Py2. Note though that I rewrote some extensions from scratch in a (hopefully) clean, documented, understandable and notably more efficient/faster manner. If you want that changes too, you'd have to extract my changes from this PR too and fix all merge conflicts coming from that new state. |
|
I fully understand that. After you put so much (way too much I would say) efforts into this, and mixed this huge variety of changes into a PR which I cannot merge, I am not asking you to produce more work. I'm thankful for what you've done, I'm sorry you did it the way you did and I'm not expecting you to split this into workable WIPs. If some of these changes go through (and some should, whether we move to python 3 or not, that in itself really illustrates the need for modularity and isolation here), extra work will be required and I'm not suggesting that falls onto you. |
|
@clefebvre And I fully understand your point as a the LM maintainer. Maybe I wouldn't merge such a PR either. But—just to explain my decision back then—I felt that splitting the work into several PRs didn't make sense because, as I said, all depends on |
|
We did. And I kind of agree with you on putting extensions and extension-system into the same bag and thus the same PR. We sometimes split dependent PRs (and sometimes we have to, for instance when they affect distinct projects, that's often the case in Cinnamon for instance... a WIP affecting the settings daemon + some lib + the settings + the screensaver or whatever), and it's ok, as long as we get it all done during the cycle. It's not really an issue one way or another. Both approaches have their pros and cons. What's more problematic is the merge of the folder switcher, the renaming/refactoring, the bug fixes, basically all the work you've put into that after/during the python 3 migration. I can't really have the ability to discuss them in isolation and reviewing them is much more complicated than reviewing the migration itself. Other than the work you've done here, your comments and the situation we got ourselves into... all of this is also helping us. I do many different things within Linux Mint. The hardest part of my job is to turn down help or to refuse work that has already been done. It is not easy to listen to criticism but it is valuable. You don't know this but your comments were discussed by many developers and this led to a very long discussion about style and best practices. Many disagreed about various things but we eventually decided to set up developer guidelines and put down on paper what felt important to many of us. Today, I drafted a new section to list recommendations on pull requests. This document is very new and it can certainly get a lot better, but it's a start: https://www.gitbook.com/book/linuxmint/developer-guidelines/details So there you have it. It wasn't very pleasant, but I just wanted to show you. Some of your work might help implementing a potential move towards GTK3, but it's not just that. Your negative experience on this PR is helping us as well. |
|
Okay, thank you for your elaboration. I'm kind of glad I could help—even though in a different way I intended 🍻 |
|
And what now, does it would be merged in some future time? |
|
And what if nemo-python would support both python versions? nemo-python could be
|
|
@brmmm3 that's interesting. I never really thought about this. This would be great. |
|
I've already modified the code. It was easy. A bit more tricky now is the Regards Martin Am 26.09.2016 11:49 Vorm. schrieb "Clement Lefebvre" < @brmmm3 https://github.com/brmmm3 that's interesting. I never really — Reply to this email directly, view it on GitHub |
|
The easiest and IMHO cleanest way to support both is to modify Doplers nemo-
|
|
@brmmm3 were you successful in the end, did you manage to make this work? |
|
Hi, I've merged the two existing versions of the nemo-python plugin into one to Best regards, Martin
|
|
Ok, well it was worth trying anyhow. Thanks @brmmm3. I guess we're back to square one. We can try planning that for 3.4. We're just a few days from 3.2 right now. |
|
Hi everyone, Thanks for your patience with this. We'll do the following:
That gives rabbitvcs 6 months to anticipate a change. I'm not sure it's enough, assuming it's possible. But it's better than just breaking compatibility overnight. |
clefebvre
changed the title
|
No response from rabbitvcs. I'm happy to discontinue support for it and to move to python3. |
|
Follow up on this PR. This didn't make it in 3.6. There's no hurdles left for this to happen, it's just that we had to focus on other things so this was left aside. We'll try to migrate to python 3 for 3.8. There's no real hurry, but most of the work is done in this PR already so it's just a matter of re-applying changes and testing things to make sure it all works. We'll get it done eventually, thank you for your patience. |
|
Hi guys, I'm the maintainer of RabbitVCS. I made a new RabbitVCS release in June that fixed a bunch of bugs and prepared the way for a future Python3 release, using the six module. The nemo extension that we have has also been updated, so it should run in python3. The RabbitVCS UI/backend code still requires python2, for now, but I'm hoping to get some time to work on it. |
|
Hi @adamplumb, Shall we delete the rabbitvcs extension we have in this repository for the time being? We can rely on yours in the meantime and decide late whether to bring it back here or if you want to develop it yourself? We can proceed to migrate to python3 then also. |
|
If you want you can open a pull request against the rabbitvcs repo to pull
in any changes you've made and we can maintain the extension in our repo.
…On Dec 31, 2017 6:43 AM, "Clement Lefebvre" ***@***.***> wrote:
Hi @adamplumb <https://github.com/adamplumb>,
Shall we delete the rabbitvcs extension we have in this repository for the
time being? We can rely on yours in the meantime and decide late whether to
bring it back here or if you want to develop it yourself?
We can proceed to migrate to python3 then also.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#145 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGMAP5FYrpUJAaRZ_1vcvUjI8x-G70Tks5tF3NbgaJpZM4G4tVS>
.
|
|
no longer needed |
|
Is it planned to merge nemo-metadata-tab and the other changes for those plugins? |
|
We don't maintain that plugin - all the ones that we maintain have been ported to python3. You'll need to contact whoever maintains that plugin. (I see some PPAs for it but I'm not sure where the actual source is maintained). |
As Python 2 will be discontinued and I don't want to see nemo-extensions depend on that gray version after end-of-support, I ported all Python scripts to the new version. For the source package of
nemo-pythonthe minimum version is 3.3 now which is supported since around Ubuntu Quantal/Raring, Debian Jessie and in all supported Fedora versions. The extensions are satisfied with Python 3.0 or 3.1.Many extensions were in bad shape concerning programming standards, conventions and documentation. As we know, this makes it hard to maintain software and introduce new features or fix bugs without introducing new bugs e.g. due to unknown side effects. Moreover, by cleaning up the code and simplifying it where possible, performance issues were addressed as the old code often made unnecessary checks, loops or system calls.
Details on the changes can be found in the corresponding commit messages. Here are the most prominent ones:
nemo-compare: f66d179 bea81f0
nemo-dropbox: 744da22
nemo-emblems: 603c8d0
nemo-folder-color-switcher: e7f20ae e921dd9
nemo-metadata-columns: 722f809 cf6d1f8 d3308bb 25a3d9f
values
nemo-metadata-tab: 60fe0e2 fd7d7c7 cf6d1f8 d3308bb 25a3d9f
nemo-pastebin: bd3f90f
nemo-terminal: 4dfe557
nemo-rabbitvcs:
As mentioned, (nemo-)
folder-color-switcherwas imported into this repository since it seems to belong here. Allcajaparts were removed (there is acaja-extensionsrepository for that).In addition to the changes listed above all build files received updates and follow a mostly consistent style now. E.g. all Python extensions use
pybuild, all C extensions provide the sameautoconflayout in theirconfigure.acfiles. Besides, some deprecation warnings during the build process were addressed; some translation files have updated line references. Henceforth all refactored extensions present proper README files. Important changes for each extension are mentioned in*/debian/changelog.All extensions are tested with Linux Mint 17.2 and 17.3 and work flawlessly for several weeks.
This commit closes or resolves the following GitHub issues (or makes them obsolete):