launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

I hope that a few opinionated engineers can help identify where some
un-owned code should live.

Some of you have seen my branches update code to import from true module
locations instead of canonical.launchpad.interfaces. I am landing these
because my efforts to remove even a few lines from the c.l.i interfaces
were results in cyclic import hell. I then started a long march to
update all callsites that wrongly import from c.l.i. This 32,000+ line
branch also failed from cyclic imports. I am landing smaller branches
that fix what can be fixed, and reveals the underlying problems.

I believe the single greatest problem are the modules in
canonical.launchpad.interfaces. I know that some efforts to move them
failed because of cyclic import complications. I think the proper course
is to continue fixing the bad callsites, while moving the unclaimed
modules in a trial and error fashion. I personally think Account and
EmailAddresses are the most common problem because of their coupling
with Person.

Here is a list of unowned modules that need homes:

account.py
The foundations team has proposed deleting it or renaming it. If it
really is to be nothing more than OpenId identifiers, then I image it
should live in lp.services.openid

authserver.py
?

authtoken.py
The foundations team created this for OpenID integration, but we changed
plans again. I think this can be deleted or some of it returned to
LoginToken

emailaddress.py
EmailAddress was Launchpad's means of managing identity, then it was
subordinated to Account. If the foundation's team does intend to
decouple EmailAddress from Account, I think EmailAddress belongs in
lp.registry. If we continue to believe it is about identity, the
lp.service.identity might be a place for it. Account could also go to
this location.

gpghandler.py
lp.services.gpg

launchpad.py
Most of this belongs to lp.app. I favour moving it there then moving the
exceptions later.

launchpadstatistic.py
lp.app

librarian.py
lp.services.librarian

logintoken.py
I do not think this is used for login anymore. I think it is a
ConfirmationToken and that the primary use of it is by lp.registry.

looptuner.py
lp.services.looptunner

lpstorm.py
lp.services.storm

mailbox.py
lp.services.mail, looks like the migration was not completed

mail.py
lp.services.mail, looks like the migration was not completed

message.py
lp.services.mail, but we use this in a broader sense, maybe
lp.services.message?

oauth.py
lp.services.oauth

openidconsumer.py
lp.services.openid

packagerelationship.py
lp.soyuz

pathlookup.py
lp.services.webapp

schema.py
?

searchservice.py
lp.services.search

temporaryblobstorage.py
lp.services.librarian

validation.py
lp.services.validation, but could be lp.services.field


-- 
__Curtis C. Hovey_________
http://launchpad.net/

Attachment: signature.asc
Description: This is a digitally signed message part