>>>>> Jonathan Lange <j...@mumak.net> writes:
<snip/>
>> It seems to me like we should keep lp:udd about the package importer,
+1, or find another name but this hasn't been needed so far.
>> and then split out the functionality you need. Does that make
>> sense, or do you want to do it the other way around?
>>
> Either way seems right to me. I guess if we split out the stuff we
> need, that means less work for you.
You may even *import* the stuff you need. This way we should still be
able to merge in both directions on the common parts if needed.
But until I better understand which "stuff" you want to reuse, it's hard
to say.
While most of the code in lp:udd is below import_package.py which you
replace, you don't need it.
But what does this left ? The mass_import script ? There are already
some strong dependencies between this script and the various databases.
And the databases themselves are used by mass_import so untangling them
seems like the first needed step.
Looking at pkgme/devportalbinary/database, it seems you already define
your own db and don't care about the existing one.
Are you sure you don't want to define your own mass_import script ?
The current design separate the subprocess/thread management (in
udd/threads.py) from the db usage which is defined in mass_import
itself.
In this case, you can simply *use* lp:udd and modifying it should be the
exception rather than the norm.
> Well, you'd have to add a dependency and manage deployment a
> little differently, but that's it.
Care to elaborate on that ? The deployment is already pretty manual so
one more step may not be an issue but I'm more concerned by the fallouts
introduced by changes the package importer don't need at all.
Vincent
--
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
