Menu
▾
▴
pythius-developers
|
From: Frank T. <ft...@ne...> - 2002-07-12 20:47:21
|
As I've mentioned before, I've had some worries about incorporating the aop.py module into Pythius, since it seems fairly stale. Also, I feel that many people would be simply looking for an AOP module, and, if they do come across Pythius, might be confused in the aop.py module interacts with the rest Pythius, etc. I think the goals of Pythius and the aop.py module are quite different; Pythius could depend on aop.py for some of its metrics, but the aop module is quite independent, quite usable on its own. Therefore within the next few days I plan on developing/distribution the aop.py module as a project of its own. Hopefully distributing it as an independent, small module might increase its usage. -- Frank Tobin http://www.neverending.org/~ftobin/ |
|
From: Juergen H. <jh...@we...> - 2002-07-12 21:11:42
|
On Fri, 12 Jul 2002 16:47:27 -0400 (EDT), Frank Tobin wrote: >Therefore within the next few days I plan on developing/distribution th= e >aop.py module as a project of its own. Hopefully distributing it as an= >independent, small module might increase its usage. You could also open a new CVS module, and a new package in the release section. But this is totally up to you. Ciao, J=FCrgen |
|
From: Frank T. <ft...@ne...> - 2002-07-13 22:51:36
|
Juergen Hermann, on 2002-07-12, wrote: > You could also open a new CVS module, and a new package in the release > section. But this is totally up to you. That seems like a good idea. I like the idea of keeping the referenced name of the module pythius.aop, to help people still think of it as the same product. I think putting it into its own cvs module will help people get just the parts they want out of Pythius, sort of like with KDE, you can get library support, kdelibs, by itself, or if you want more, kdebase. -- Frank Tobin http://www.neverending.org/~ftobin/ |
|
From: Frank T. <ft...@ne...> - 2002-07-19 03:27:09
|
Juergen Hermann, on 2002-07-12, wrote: > You could also open a new CVS module, and a new package in the release > section. But this is totally up to you. Doing it this way, I'm trying to figure out how get the installed aop module named something like pythius.aop. The trouble is that in order to have pythius.aop, pythius/__init__.py needs to exist (to indicate that pythius/ is a package directory). The current pythius distribution gives this file (so things like pythius.util and pythius.grok can exist), so if a separate pythius.aop distribution gave it also, we would have two separate distributions giving the same file. Until about 5 minutes ago, I didn't have an idea on how to approach this cleanly, but now I think I have a solution. In noting that pythius/__init.__.py doesn't really do anything, I think the way to do this would be to have both packages give the file, but have it be a zero-length file. This way, there would be 'change' if you happened to install old-style pythius or pythius.aop first, and followed it up with the other. Does a zero-length pythius/__init__.py seem like a good solution? -- Frank Tobin http://www.neverending.org/~ftobin/ |
|
From: Juergen H. <jh...@we...> - 2002-07-19 08:05:22
|
On Thu, 18 Jul 2002 23:27:21 -0400 (EDT), Frank Tobin wrote: >Does a zero-length pythius/__init__.py seem like a good solution? No, since I hate those, not only due to the fact that they in consequence contain no package doc string. So scratch zero-length, and replace it by "identical", which solves all practical problems for me. Remaining problems are that there should probably be a way to check what is installed (aop only, full, etc.) Also, on 2nd thinking I despise the idea to create a 2nd cvs module, duplicating setup.py and all stuff. A better way would be to have options in setup.py (or a 2nd setup_aop.py) that just packages the right stuff. This way, it's much easier to create tailored distributions. Let me look at it this weekend. Ciao, J=FCrgen |
|
From: Frank T. <ft...@ne...> - 2002-07-19 15:28:12
|
Juergen Hermann, on 2002-07-19, wrote: > No, since I hate those, not only due to the fact that they in > consequence contain no package doc string. So scratch zero-length, and > replace it by "identical", which solves all practical problems for me. That's a reasonable objection. The only problem with 'identical' is that there are issues of one changing in one cvs module, and not in the other (nevermind the fact that CVS $Id$ tags would be different). > Remaining problems are that there should probably be a way to check > what is installed (aop only, full, etc.) Why? > Also, on 2nd thinking I despise the idea to create a 2nd cvs module, > duplicating setup.py and all stuff. A better way would be to have > options in setup.py (or a 2nd setup_aop.py) that just packages the > right stuff. I wouldn't be duplicating, since the setup.py and such would be significantly simpler than the current one, and more able to accurately describe the pythius.aop module (e.g., differences such as LGPL, etc). > This way, it's much easier to create tailored distributions. I'm not following what you mean here. -- Frank Tobin http://www.neverending.org/~ftobin/ |
|
From: Frank T. <ft...@ne...> - 2002-07-22 02:11:28
|
Juergen Hermann, on 2002-07-19, wrote: > A better way would be to have options in setup.py (or a 2nd > setup_aop.py) that just packages the right stuff. I didn't catch this sentence on my first reading, so I'm addressing it now. At fisrt, this seems like a good idea, but I'm ambivalent about the non-standardness of this. It might be the least evil solution, though. -- Frank Tobin http://www.neverending.org/~ftobin/ |
|
From: Juergen H. <jh...@we...> - 2002-07-22 10:16:05
|
On Sun, 21 Jul 2002 22:12:07 -0400 (EDT), Frank Tobin wrote: >I didn't catch this sentence on my first reading, so I'm addressing it >now. At fisrt, this seems like a good idea, but I'm ambivalent about t= he >non-standardness of this. It might be the least evil solution, though.= Well, having a package in two different forms ist very non-standard, too= . Actually, distutils and Python in general do not really support division= s below the top-level namespace. The non-standardness of having a setup.py that checks some option (--aop= - only) can be restricted to the developer side (especially if you do a "sdist" and that source package remembers it's aop-only). Or viewed from the other side, if we really have two separate cvs module= s, we have to have separate python packages, too. Everything else, besides those two options, leads into evilness. Ciao, J=FCrgen -- J=FCrgen Hermann, Developer (jh...@we...) WEB.DE AG, http://webde-ag.de/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X