EP2019 | Improved repository layout #891
Comments
|
@kushaldas, after a short discussion with @ntoll, about Mu's repository layout, he suggested I ping you about the files you helped create under the
Thanks a lot in advance for any input you may provide. One file there, |
|
@tmontes On GNOME this is used by gnome-software to provide a detailed description of Mu, KDE store-thing does similar
(sorry I've not been around so much lately, been distracted by other things which shall not be named...) |
|
@ZanderBrown, thanks for the info. Could one say, thus, that it is somehow "packaging" related? If so, would there be any negative implications in moving it under, say, |
|
@tmontes well given the other proposals downstream packing is already broken so we may as well Of course the traditional location would be /data Not sure the benefit in giving a single file it's own directory? |
@ZanderBrown, I'm not sure I understand your words perfectly. What do you mean by "other proposals" and "already broken"? Are you referring to the general proposal of layout change I'm describing here? Something else? My purpose is to try and make it easier for someone with little/no prior knowledge of Mu and its repo layout to grasp what's going on with as little effort as possible (and I think that some moving around/renaming helps with that). But that should not come at a (big) cost to others, in particular others that work on packaging Mu (itself quite a challenge, given the wide variety of platforms Mu wants to be distributed over). I'm trying to find out a good balance, here. :)
In my mind, having all packaging-related files (non-source, non-docs, non-tests) under a the already existing I myself don't find it offending at all if a given directory contains a single file if that directory's name/path helps understanding what that file might be about. But I'm happy to hear other perspectives. :) Thanks for your input. |
|
Sorry if i was unclear
This, but with new modes + deps packagers where going to have work to do anyway
Makes sense
Do we currently have any fedora specific files?
I assume this means moving /debian? Unfortunately that gets back to "should not come at a (big) cost to others" in that moving /debian doesn't work But the alternative is ditch it, ideally this would be maintained somestream and considering the last changelog entry is Similarly Raspbian history seems to follow that of debian although has spit to |
|
Preliminary note: while I'm mostly at home with Python packaging, I know absolutely zero about the packaging requirements / complexities / processes / tools regarding Linux distribution specific packaging. I'm just trying to figure out a way of organising the repository in such a way that what-is-what and where-is-what becomes as clear and as obvious as possible: giving good names to directories and moving a few files around can contribute to that, hopefully! :)
Still not 100% sure, but assuming that moving the current PS: Read the AppStream docs you linked to (thanks!) and couldn't identify any specifics on that.
Glad we agree.
All I know is what @ntoll told me when I asked him "what are these files under As for the other two files there, an PNG icon and what looks like a
Oh, is that a fact? :( Does the Debian project require source repos to have a
Let me see if I get your thesis right: Debian packagers have a clone of the repo with a branch that holds the equivalent of the current
Hmmm. Would you have any pointers of who to contact to validate these hypothesis? :) PS: Thanks a lot for sharing all these details! |
No, not yet anyware Zander tries to look busy
Yes :-)
It's the launcher as used by everything following this spec
The icon used by the .desktop, ideally this would be an SVG however
I imagine debian needs them as well? Not a udev person though
Yep, tried to find a definitive source that puts this in black 'n white but alas I failed
Yes/No, Debian have there own repo with the packaging information that references this repo (or at least a tarball of it) You can see Fedora's such repo on Pagure here (note RPM packaging uses a single ... and after checking through half of packages.debian.org we find the repo on Salsa for Debian (notice the git history is quite different to ours) For Raspbian you would have to as the Foundation as they are maintaing patches on top of Rasbian itself but as you would expect it's based on Debians repo (as evident by the changelog)
See above :-) |
|
(a good tool for finding info about a package is repology, might be of some interest to you) |
|
@ZanderBrown, thanks a lot: that's very useful information. I'll try and reach out to distribution specific packagers and see if moving a few files around and even throwing others away might be a good fit for them... Let's see how that goes. |
|
FYI, I just emailed the Mu package maintainer for a bunch of Debian-like distributions (found in the link @ZanderBrown shared above):
Let's see how that goes. :) |
|
Nick is here: @knowledgejunkie , see #58 for related discussion |
Oh, I had no idea! Feeling somewhat silly. :) Thanks. That should simplify a more direct interaction. |
|
Sharing a valuable Debian document which I plan on reading: Debian Upstream Guide. |
|
Relevent extract:
|
|
From the extract (thanks!) it seems that downstream Debian packaging doesn't care much about whether the source repository contains or not the packaging related files: or, maybe they prefer the source repo not to include it at all (unless we want to support bleeding edge Debian packaging, for which I fail to see a big benefit given that a Nevertheless, I received a friendly feedback email from @knowledgejunkie who was nice enough to help out with direct feedback in this issue. My current perception is that moving |
|
Apologies for the delayed response... With respect to "officially" packaging mu-editor for Debian, we throw away /debian completely when we ingest a new release. With mu-editor (and the associated "Debianisation" to generate a Debian Free Software Guidelines-compatible (DFSG) binary package) now available in Debian stable, Ubuntu 19.04 and many derivatives, I'm not sure how much use the existing upstream /debian/ packaging files will get from end-users. As @ZanderBrown mentioned, Debian tooling expects the "Debianisation" files to exist in /debian/, so moving them out of this path will cause breakage for end users wanting to build a deb using these files. When ingesting a new upstream release of software, the Debian tooling can automatically exclude files and directories from the source tree if such files are deemed unnecessary (such as CI/CD configuration, or Mac/Windows packaging), are not freely licensed, or are not compatible with Debian Policy and/or DFSG for other reasons. Reorganising the upstream repository layout for e.g. packaging may simplify the number of items included in the exclusion list (which would need to be kept up to date), but does not really make a difference. Similarly, moving mu/ under src/ will require updating the exclusions list to use the new path. The current list of excluded files can be seen at https://salsa.debian.org/python-team/applications/mu-editor/blob/debian/master/debian/copyright We install the AppStream data, desktop file and icon from conf/. The location of these files in the upstream repo are not important - the important step is installing them into the correct system location when the package is installed. We'd just need to update references to their new location were they to move. The Debian packaging repository is not a clone of this repo "with added sparkles", but rather a completely separate repository with each Mu release ingested as a tarball in a commit to the "clean" upstream branch. Packaging work happens in the master branch, into which the new upstream release is merged. Building and testing of the source happens automatically - if a "python setup.py ..." works with the new repo layout it should continue to work for Debian packaging. Sometime tweaks to the testing framework are required e.g. to install test assets or to hot-replace files removed from the source at build time (e.g. the bundled font) but again this tends to be down to how things build in clean Debian chroots rather than how the upstream codebase is organised. We carry quite a few patches to bend the source to our will when necessary. We have to remove the bundled Source Code Pro font and replace it with an alternative available in Debian. We also need to replace the bundled uflash script and micro:bit hex with references to the separately-packaged uflash script and MicroPython runtime on Debian. These issues reflect fundamental differences between the upstream and DFSG-compatible Debian packages, and will not be affected by layout changes to the repository. Anyone interested in seeing the current patchset can check the debian/patches directory in the mu-editor salsa.debian.org repository linked above. I hope this information is of some use - if there are any follow-up questions please don't hesitate to ask. |
|
That's pretty much what I thought, although probably failed to communicate |
Context
This is an "umbrella" issue that follows from a brief discussion I had with @ntoll at EuroPython yesterday, about many Mu related, somewhat high-level, project orientation topics.
One of those is about improving the repository layout such that it becomes, in a word, more readable. That should simplify everybody's lives, especially those who are new to the Mu's codebase.
I'll list the few ideas we discussed as individual "checkboxes" to allow for discussion. From there, we may either relate each such task to a dedicated issue, or have it "closed" by means of one or more PRs.
Of course we can also say we don't wan't do address some of them, add a few, etc. :)
Ideas
Move to an
src/based layout in such a way that what is now themu/directory/package at the root, is moved tosrc/mu/. There are multiple benefits to this, in particular related to test and packaging reliability (see, for example, the first part of the article at https://hynek.me/articles/testing-packaging/). There might be a tradeoff in that tracking history changes with git becomes less easy, but that is something that, in time, will no longer be an issue.Re-arranging files in the root:
ROADMAP.rstto docs?force-rechecks.txt?run.py, there's no longer a good motive to keep it, AFAICT. As a matter of fact, it leads to confusion in that there are now at least two ways to run Mu, when developing.todo.txtand create issues if needed. Then drop the file.win_installer.pyto thepackage/directory.Re-arrange the files in the
package/directory.mac,lin,winsub directory (or more, on per linux dist?).package/README.rstlooks outdated: integrate what's relevant in the docs and delete it.__init__.pyfrom there: it is not a package.debiandirectory in the root here.Not sure what the
conf/directory is, but seems packaging related. @ntoll suggested pinging Kushal Das, any pointers? :)General code layout:
mu/logic.py: Editor class is big, but there are many other bits and pieces.mu/modes/base.py: move MicroPythonMode class to its own module?mu/interface/dialogs.py: break apart with one module per dialog?mu/interface/main.py: break apart with one module per component?mu/interface/panes.py: break apart with one module per pane?mu/interface/themes.py: break apart with one module per theme?Could we delete most (all?) branches from the repository? It certainly increases confusion for newcomers, wouldn't you agree?
Parting Thoughts
This is it, AFAICT. Would love to hear feedback before getting to some of this action. :)
Thanks!
PS: Will create more issues to address other topics I reviewed with @ntoll.
The text was updated successfully, but these errors were encountered: