Something that’s bugged me for while in portage was the crappy namespace handling we had since whenever we moved the python modules to \/usr\/lib\/portage\/pym. Originally there was no real problem as we only had a single module portage.py, so all you needed was a ‘import portage’, but over time more modules were created, which Nick started to name portage_foo.py due to the lack of a “portage” python package to use as container. Also there were a number of modules without any “portage” part in the name, such as xpak, cvstree, output or the cache package, which could potentially cause a namespace collision with other packages in site-packages or even the standard library, not a very pleasant thought.
\nBut as of today that’s history, I finally fixed this annoyance and moved all the portage related code into the new “portage” package (so portage.py is now portage\/__init__.py and portage_foo.py is now portage\/foo.py). For now the code is mostly a 1:1 translation, but over time it hopefully gets a bit cleaner by removing redundant qualifiers. Also this now allows us to split the big portage.py (or now __init__.py) up further without fearing namespace collisions, I’ll probably move the dbapi classes into their own package later this week.
\nBut what does this all mean to you? If you’re just a normal user it shouldn’t affect you in any way (assuming I didn’t screw up anything and Zac updates the ebuild accordingly). If you have some custom scripts or are a developer of a tool using the portage API you should prepare for updating it after portage-2.1.3 is released, though for the time being the old names should just continue to work as I’ve also added some symlinks to avoid a large-scale API breakage.<\/p>\n
On another note I fully agree with Diego<\/a> on the idea of splitting the tree up. I’ve never been a big fan of the recent overlay hype, but at this point it’s still manageable. Also besides any technical problems a tree split would increase the “repo hunting” problem which we’re already starting to see and is IMHO one of the major downsides of most other (rpm-based) distributions, and that’s something I’d like to avoid in Gentoo.<\/p>\n","protected":false},"excerpt":{"rendered":" Something that’s bugged me for while in portage was the crappy namespace handling we had since whenever we moved the python modules to \/usr\/lib\/portage\/pym. Originally there was no real problem as we only had a single module portage.py, so all you needed was a ‘import portage’, but over time more modules were created, which Nick … Continue reading Namespace sanitizing and splitting up the tree<\/span><\/a><\/p>\n","protected":false},"author":46,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[3,6],"tags":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/genone\/wp-json\/wp\/v2\/posts\/16"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/genone\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/genone\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/genone\/wp-json\/wp\/v2\/users\/46"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/genone\/wp-json\/wp\/v2\/comments?post=16"}],"version-history":[{"count":1,"href":"https:\/\/blogs.gentoo.org\/genone\/wp-json\/wp\/v2\/posts\/16\/revisions"}],"predecessor-version":[{"id":44,"href":"https:\/\/blogs.gentoo.org\/genone\/wp-json\/wp\/v2\/posts\/16\/revisions\/44"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/genone\/wp-json\/wp\/v2\/media?parent=16"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/genone\/wp-json\/wp\/v2\/categories?post=16"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/genone\/wp-json\/wp\/v2\/tags?post=16"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}