SETUPTOOLS - Loading Eggs which do not have an egg_info
I have the following use-case: within an application, i like to load several plugins from an folder, without any user-interaction app/plugins/pluginone app/plugins/plugintwo the plugins (standard sources prepared for setuptools, coming from svn) are arranged like this: pluginone/one pluginone/setup.py #standard setup.py file Is there any documented way to load such a "raw egg" (egg sources without a generated egg-info) into the application, without the need to generate the egg-info? . -- http://lazaridis.com
At 03:41 PM 12/7/2006 +0200, Ilias Lazaridis wrote:
Is there any documented way to load such a "raw egg" (egg sources without a generated egg-info) into the application, without the need to generate the egg-info?
No. Of course, if you know where the plugin directories are, you can always run their "setup.py egg_info" to generate it.
Phillip J. Eby wrote:
At 03:41 PM 12/7/2006 +0200, Ilias Lazaridis wrote:
Is there any documented way to load such a "raw egg" (egg sources without a generated egg-info) into the application, without the need to generate the egg-info?
No. Of course, if you know where the plugin directories are, you can always run their "setup.py egg_info" to generate it.
This is what I do, from within my programm, and it works fine.
But I like to avoid this step.
-
I currently try to use the setuptools code to instantiate an egg from
the setup.py file (which contains all information), and to apply then
the functions from pkg_resources.
Looks somehow like this:
from distutils.core import run_setup
dist = run_setup( setuppys[0],None,'init')
print dist
loaded_components = []
module = []
import pkg_resources
for name in pkg_resources.get_entry_map(dist,'trac.plugins'):
entry_point =
pkg_resources.get_entry_info(dist,trac.plugins', name)
entry_point.load()
but this fails, I must have missed some point.
(('Expected string, Requirement, or Distribution', ))
although "dist" is an:
At 06:24 PM 12/7/2006 +0200, Ilias Lazaridis wrote:
Looks somehow like this:
from distutils.core import run_setup dist = run_setup( setuppys[0],None,'init') print dist
loaded_components = [] module = []
import pkg_resources for name in pkg_resources.get_entry_map(dist,'trac.plugins'): entry_point = pkg_resources.get_entry_info(dist,trac.plugins', name) entry_point.load()
but this fails, I must have missed some point.
(('Expected string, Requirement, or Distribution', ))
although "dist" is an:
That Distribution is a distutils distribution, not a pkg_resources distribution.
How can I create an egg representing object (from the sources/setup.py), from which I can load the entry-points afterwards, without having to generate an egg_info on the file-system?
You can take the dist.Distribution object's entry_points and parse it to create an entry point map. See http://peak.telecommunity.com/DevCenter/PkgResources#creating-and-parsing for details. In particular, you want to use: ep_map = EntryPoint.parse_map(dist.entry_points) entry_point = ep_map['trac.plugins'][name] There are several big drawbacks to this approach, because you're basically bypassing the entire eggs system. Here are two of the things that will break when you do this: * Plugins will not be able to depend on other plugins * Plugins will not be able to depend on other Python packages or projects I can't guarantee that there aren't other things that will break, too. I don't recommend that you use this approach in a published or production system, just because you don't like generating the egg-info on disk. It's there for several reasons, not the least of which is that it allows you to ship plugins as single .egg files. See also: http://peak.telecommunity.com/DevCenter/PkgResources#locating-plugins which shows how to do automatic plugin discovery and dependency resolution. This is another example of something that won't work with the approach you're trying to use.
Phillip J. Eby wrote:
At 06:24 PM 12/7/2006 +0200, Ilias Lazaridis wrote:
Looks somehow like this: ...
That Distribution is a distutils distribution, not a pkg_resources distribution.
ok
How can I create an egg representing object (from the sources/setup.py), from which I can load the entry-points afterwards, without having to generate an egg_info on the file-system?
You can take the dist.Distribution object's entry_points and parse it to create an entry point map.
See http://peak.telecommunity.com/DevCenter/PkgResources#creating-and-parsing for details. In particular, you want to use:
ep_map = EntryPoint.parse_map(dist.entry_points) entry_point = ep_map['trac.plugins'][name]
Although not the prefered solution, I've tried this: import pkg_resources from distutils.core import run_setup dist = run_setup( setuppys[0],None,'init') ep_map = pkg_resources.EntryPoint.parse_map(dist.entry_points, dist) ep_list = ep_map['trac.plugins'] print ep_list for name, entry_point in ep_list.iteritems(): print name print entry_point try: entry_point.load() except pkg_resources.DistributionNotFound, e: ... File "C:\prg\py24\lib\site-packages\setuptools-0.6c3-py2.4.egg\pkg_resources.py", line 1829, in load if require: self.require(env, installer) File "C:\prg\py24\lib\site-packages\setuptools-0.6c3-py2.4.egg\pkg_resources.py", line 1842, in require working_set.resolve(self.dist.requires(self.extras),env,installer)) AttributeError: Distribution instance has no attribute 'requires'
There are several big drawbacks to this approach, because you're basically bypassing the entire eggs system. ... (elaborations)
. -- http://lazaridis.com
At 08:57 PM 12/7/2006 +0200, Ilias Lazaridis wrote:
File "C:\prg\py24\lib\site-packages\setuptools-0.6c3-py2.4.egg\pkg_resources.py", line 1829, in load if require: self.require(env, installer)
Yeah, you need to pass 'require=False' to entrypoint.load(). See: http://peak.telecommunity.com/DevCenter/PkgResources#entrypoint-objects As I said, dependency resolution for these non-egg things isn't going to work right.
Phillip J. Eby wrote:
At 08:57 PM 12/7/2006 +0200, Ilias Lazaridis wrote:
File "C:\prg\py24\lib\site-packages\setuptools-0.6c3-py2.4.egg\pkg_resources.py", line 1829, in load if require: self.require(env, installer)
Yeah, you need to pass 'require=False' to entrypoint.load(). See:
http://peak.telecommunity.com/DevCenter/PkgResources#entrypoint-objects
As I said, dependency resolution for these non-egg things isn't going to work right.
Setuptools seems to be a very huge work. I appreciate your efforts in having made my live (as a user) with python easier. Thank's a lot for your assistance! (will sleep a little, hopefully tomorrow things become more clear.) . -- http://lazaridis.com
At 08:57 PM 12/7/2006 +0200, Ilias Lazaridis wrote:
ep_map = pkg_resources.EntryPoint.parse_map(dist.entry_points, dist)
By the way, I missed this line in your email before: you should *not* pass dist as the second argument here. That method is looking for a pkg_resources.Distribution, not a distutils.Distribution. distutils.Distribution (and setuptools.dist.Distribution) represent *source* distributions that have not been built yet. pkg_resources.Distribution objects represent *built* and *importable* distributions. They have different data structures and behaviors. distutils Distribution objects have data and methods for running commands and building, while pkg_resources.Distribution objects know about import locations, entry points, package versions, and things like that. You can't pass a distutils Distribution into *any* pkg_resources APIs, or vice versa -- they are utterly incompatible objects.
Phillip J. Eby wrote:
At 08:57 PM 12/7/2006 +0200, Ilias Lazaridis wrote:
ep_map = pkg_resources.EntryPoint.parse_map(dist.entry_points, dist)
By the way, I missed this line in your email before: you should *not* pass dist as the second argument here. That method is looking for a pkg_resources.Distribution, not a distutils.Distribution.
ok, this one works now (btw: either with "dist" or without it. but i've removed it, as you've suggested).
distutils.Distribution (and setuptools.dist.Distribution) represent *source* distributions that have not been built yet.
ok
pkg_resources.Distribution objects represent *built* and *importable* distributions. They have different data structures and behaviors. distutils Distribution objects have data and methods for running commands and building, while pkg_resources.Distribution objects know about import locations, entry points, package versions, and things like that. You can't pass a distutils Distribution into *any* pkg_resources APIs, or vice versa -- they are utterly incompatible objects.
I have missed the existence of "pkg_resources.Distribution" totally (was looking on "setuptools.dist.Distribution / disutils.Distribution" ) are "pkg_resources.Distribution" objects finally the internal representation of eggs? . -- http://lazaridis.com
Phillip J. Eby wrote:
At 01:42 PM 12/8/2006 +0200, Ilias Lazaridis wrote:
are "pkg_resources.Distribution" objects finally the internal representation of eggs?
Yes.
ok. Possibly the class should be named "pkg_resources.Egg" or "pkg_resources.EggDistribution" in order to become more descriptive. - (sidenote: I am just finshing some code, thus I can point you to some examples of the usage-context) . -- http://lazaridis.com
At 03:35 PM 12/8/2006 +0200, Ilias Lazaridis wrote:
Possibly the class should be named "pkg_resources.Egg" or "pkg_resources.EggDistribution" in order to become more descriptive.
No. It's also used to track source distributions being downloaded from PyPI, and even .win32.exe distributions. It's not limited to eggs alone, nor to any one format even of eggs.
Phillip J. Eby wrote:
At 06:24 PM 12/7/2006 +0200, Ilias Lazaridis wrote:
Looks somehow like this: ...
How can I create an egg representing object (from the sources/setup.py), from which I can load the entry-points afterwards, without having to generate an egg_info on the file-system?
You can take the dist.Distribution object's entry_points and parse it to create an entry point map. ... I can't guarantee that there aren't other things that will break, too. I ... (elaborations)
I understand, and I basicly would like to use the setuptools egg code. This is a special and limited use-case: The eggs do *not* need to be found by other eggs/applications, as they are used only by the application that loads them in. Thus I just want to create the egg representation in my code (to call the entry_points), whilst using the information from setup.py/sources (instead of the generated egg_info). Essentially, the code (internal in setuptools) that reads the egg_info will simply retrieve it from the setup.py (or i instantiate it somhow, and pass it to the setuptools routines) The function would be essentially: def get_an_egg(path_to_setuppy) # load setup.py # construct the egg return egg #further processing based on standard egg methods . -- http://lazaridis.com
Ilias Lazaridis wrote:
Phillip J. Eby wrote:
At 06:24 PM 12/7/2006 +0200, Ilias Lazaridis wrote:
Looks somehow like this: ...
How can I create an egg representing object (from the sources/setup.py), from which I can load the entry-points afterwards, without having to generate an egg_info on the file-system? You can take the dist.Distribution object's entry_points and parse it to create an entry point map. ... I can't guarantee that there aren't other things that will break, too. I ... (elaborations)
I understand, and I basicly would like to use the setuptools egg code.
This is a special and limited use-case:
The eggs do *not* need to be found by other eggs/applications, as they are used only by the application that loads them in.
Thus I just want to create the egg representation in my code (to call the entry_points), whilst using the information from setup.py/sources (instead of the generated egg_info).
Essentially, the code (internal in setuptools) that reads the egg_info will simply retrieve it from the setup.py (or i instantiate it somhow, and pass it to the setuptools routines)
The function would be essentially:
def get_an_egg(path_to_setuppy) # load setup.py # construct the egg return egg
#further processing based on standard egg methods
- I am a little overworked at this point, but this should be the right direction to enable setuptools to create distributions whilst using the information within setup.py (and without breaking any behaviour): in pkg_resources def register_finder(importer_type, distribution_finder): """Register `distribution_finder` to find distributions in sys.path items _distribution_finders[importer_type] = distribution_finder def find_distributions(path_item, only=False): """Yield distributions accessible via `path_item`""" importer = get_importer(path_item) finder = _find_adapter(_distribution_finders, importer) return finder(importer, path_item, only) . -- http://lazaridis.com
At 09:45 PM 12/7/2006 +0200, Ilias Lazaridis wrote:
I am a little overworked at this point, but this should be the right direction to enable setuptools to create distributions whilst using the information within setup.py (and without breaking any behaviour):
The only way I'll ever support this is if it's basically a way to automatically run the egg_info command on demand (perhaps by checking whether setup.py is newer than the .egg-info/PKG-INFO file). There are huge areas of functionality that will otherwise break -- and I'm not going to spend thirty minutes trying to write down all the ones I can think of, let alone the ones I can't think of right now. I've already given you the workarounds for you to do it in your own system, but remember that if anything breaks, it's broken. The minute that any of your plugins depend on *anything* else, or expect to use metadata generated by egg_info, the game is over. So it's never going to be a supported feature of setuptools unless the egg_info command gets run.
Phillip J. Eby wrote:
At 09:45 PM 12/7/2006 +0200, Ilias Lazaridis wrote:
I am a little overworked at this point, but this should be the right direction to enable setuptools to create distributions whilst using the information within setup.py (and without breaking any behaviour):
The only way I'll ever support this ... So it's never going to be a supported feature of setuptools unless the egg_info command gets run.
My question was from an architectural nature. If someone (for _any_ reason) want's to avoid generation of egg-info files, would he use the mechnism below to pass a finder/loader to setuptools which does not rely on the egg-info? def register_finder(importer_type, distribution_finder): def find_distributions(path_item, only=False): . -- http://lazaridis.com
At 09:03 PM 12/7/2006 +0200, Ilias Lazaridis wrote:
This is a special and limited use-case:
The eggs do *not* need to be found by other eggs/applications, as they are used only by the application that loads them in.
That's 100% irrelevant. There are a whole bunch of different ways for you to install them so that they will be used only by your application. "easy_install -md /path/to/plugins" is one of the simplest, but you can also drop .egg files directly there, or run a plugin's "setup.py develop -md /path/to/plugins" (which allows it to run from the source), etc. Once you have plugins installed (or deposited) in a plugins directory, have your app use find_plugins(), add them to sys.path, and then just load the entry points: http://peak.telecommunity.com/DevCenter/PkgResources#locating-plugins Note that in both cases, the -m option (--multi-version) is important for installing or developing plugins, as that allows you to install to a non-sys.path directory and doesn't require .pth support.
Thus I just want to create the egg representation in my code (to call the entry_points), whilst using the information from setup.py/sources (instead of the generated egg_info).
I still don't get why you can't run "develop", "egg_info", or build .egg files. If the answer is simply that you don't want to, I'd suggest getting over it. :) If there's some other reason, you haven't shared it with me yet. I suspect, however, that the actual problem is that you're not aware of one or more of the several other ways to implement plugins... that all actually work. :)
Phillip J. Eby wrote:
At 09:03 PM 12/7/2006 +0200, Ilias Lazaridis wrote:
This is a special and limited use-case:
The eggs do *not* need to be found by other eggs/applications, as they are used only by the application that loads them in.
That's 100% irrelevant.
ok
There are a whole bunch of different ways for you to install them [...]
I understand. Flexibility is very nice. But simplicity, too. My requirement is to have no additional installation steps after an svn-checkout (or unzip).
Thus I just want to create the egg representation in my code (to call the entry_points), whilst using the information from setup.py/sources (instead of the generated egg_info).
I still don't get why you can't run "develop", "egg_info", or build .egg files. If the answer is simply that you don't want to, I'd suggest getting over it. :) If there's some other reason, you haven't shared it with me yet.
The reason is "reduncancy", which I like to avoid. For simple plugins, the information is already given within "setup.py", thus duplicating it into an egg-info is "duplicating information".
I suspect, however, that the actual problem is that you're not aware of one or more of the several other ways to implement plugins... that all actually work. :)
Trac uses setuptools as it's plugin mechanism, thus I have to deal with eggs in my use case. Most (if not all) of those plugins just use the basic constructs of setuptools. In my use-case, a loader retrieves all 2nd-level directories from within a folder and loads the eggs: http://dev.lazaridis.com/base/browser/infra/tracx/loader-draft-test.py?rev=1... I had initially placed the egg-info-generation within this code, but this leads to problems with permissions etc. - and: it's redundant. - As said, as a user I am very happy with setuptools. As a developer, I would like to have more simplicity for simple use cases. I think removing the need for an egg-info would be the first step. - How does this read: Setuptools allows you to use simple python packages as eggs, without the need to generate an egg-info. This is especially usefull in development environments or in environments with a high amount of plugins. The information needed will be retrieved from within the setup.py file. If a feature requires generation of the egg-info, you'll recieve either an warning, and error or the egg-info will be generated automaticly (depending on configuration). This way, any folder which contains an setup.py file containing the configuration can serve as an "raw egg". . -- http://lazaridis.com
On Dec 8, 2006, at 5:24 PM, Ilias Lazaridis wrote:
My requirement is to have no additional installation steps after an svn-checkout (or unzip).
You could include the egg-info in your repository and distribution archive. Ronald
At 06:24 PM 12/8/2006 +0200, Ilias Lazaridis wrote:
My requirement is to have no additional installation steps after an svn-checkout (or unzip).
Then generate the .egg-info before committing to SVN, or use the "sdist" command to create your source zipfiles or tarballs, and all will be well.
The reason is "reduncancy", which I like to avoid.
For simple plugins, the information is already given within "setup.py", thus duplicating it into an egg-info is "duplicating information".
Perhaps you should then also patch Python to avoid generating .pyc and .pyo files, since these are redundant in the same way and for the same reason. :)
As said, as a user I am very happy with setuptools. As a developer, I would like to have more simplicity for simple use cases. I think removing the need for an egg-info would be the first step.
Generated egg-info is a feature, not a bug. Note that in order to use the information from the setup.py, you must import huge amounts of setuptools and distutils code, whereas normal egg operations require only the single pkg_resources module. If a project uses custom egg-info or other setuptools extensions, you must import those as well. All of this, to avoid writing some data to disk that could then be read simply and directly without involving any of those other imports! The redundancy you're complaining about is a major enhancement to startup performance. As I've said, an ability to auto-generate egg_info if a setup.py is newer than the corresponding PKG-INFO might be a useful feature. However, trying to do without generating it at all, simply isn't going to happen.
Phillip J. Eby wrote:
At 06:24 PM 12/8/2006 +0200, Ilias Lazaridis wrote:
My requirement is to have no additional installation steps after an svn-checkout (or unzip).
Then generate the .egg-info before committing to SVN, or use the "sdist" command to create your source zipfiles or tarballs, and all will be well.
There is still redundancy (and an additional step).
The reason is "reduncancy", which I like to avoid.
For simple plugins, the information is already given within "setup.py", thus duplicating it into an egg-info is "duplicating information".
Perhaps you should then also patch Python to avoid generating .pyc and .pyo files, since these are redundant in the same way and for the same reason. :)
I understand this analogy, but I think you exaggregate here.
As said, as a user I am very happy with setuptools. As a developer, I would like to have more simplicity for simple use cases. I think removing the need for an egg-info would be the first step.
Generated egg-info is a feature, not a bug. Note that in order to use the information from the setup.py, you must import huge amounts of setuptools and distutils code, whereas normal egg operations require only the single pkg_resources module.
The information in setup.py (at least for simple eggs/plugins) is simple data. Retrieving a few values directly from the setup.py (instead from an egg-info) would be fast and without any dependency.
If a project uses custom egg-info or other setuptools extensions, you must import those as well. All of this, to avoid writing some data to disk that could then be read simply and directly without involving any of those other imports! The redundancy you're complaining about is a major enhancement to startup performance.
eggs can cover 'light' needs and 'heavy' needs. Possibly for the 'heavy' needs its an enhancement. But for the 'light' needs, the overall overhead is (from my point of view) inacceptable. I go even a step further: I think python is powerfull enouth to do all this 'natively' (e.g. module attributes etc.), an without a major speed loss, even in more complex cases.
As I've said, an ability to auto-generate egg_info if a setup.py is newer than the corresponding PKG-INFO might be a useful feature. However, trying to do without generating it at all, simply isn't going to happen.
I understand. Thus the only way to avoid "egg-info" is to avoid setuptools. - I am collecting requirements on this page, possibly you are interested: http://case.lazaridis.com/wiki/Package . -- http://lazaridis.com
At 08:24 PM 12/8/2006 +0200, Ilias Lazaridis wrote:
Retrieving a few values directly from the setup.py (instead from an egg-info) would be fast and without any dependency.
In order to invoke run_setup to get the data, you must import, *at absolute minimum*: distutils distutils.cmd distutils.core distutils.dist distutils.util distutils.errors distutils.command distutils.command.install distutils.command.sdist distutils.command.install_lib setuptools setuptools.dist setuptools.depends setuptools.extension setuptools.command setuptools.command.install setuptools.command.sdist setuptools.command.install_lib Pyrex.Distutils.build_ext (if it's installed) And I didn't even go through all of these modules to see what *they* import. It also ignores any customization features usage. And you want to do all this, to avoid writing cache files?
If a project uses custom egg-info or other setuptools extensions, you must import those as well. All of this, to avoid writing some data to disk that could then be read simply and directly without involving any of those other imports! The redundancy you're complaining about is a major enhancement to startup performance.
eggs can cover 'light' needs and 'heavy' needs.
Possibly for the 'heavy' needs its an enhancement.
But for the 'light' needs, the overall overhead is (from my point of view) inacceptable.
That's because you're not paying attention to anyone's needs but your own. The use cases you consider "heavy" may be considered "light" by other people. Anything that one person does not happen to need, they will consider "heavy". Someone who doesn't use entry points, for example, will consider *your* use of them to be "heavy", even as you consider their other egg_info uses to be "heavy" instead of "light", as they consider those uses to be. Thus, your view of the situation is extremely self-centered, especially since you've received plenty of help in how to minimize the overhead -- it requires you to run a single command before checkin or source distribution, and *only* in the case where you have changed your version number or entry points. If that's too much work for you, then this is indeed the wrong toolset for you. You should instead spend large amounts of time developing and testing your own system, so that you can save that handful of keystrokes needed to type "setup.py egg_info" every once in a while. Good luck to you on that. :)
As I've said, an ability to auto-generate egg_info if a setup.py is newer than the corresponding PKG-INFO might be a useful feature. However, trying to do without generating it at all, simply isn't going to happen.
I understand.
Thus the only way to avoid "egg-info" is to avoid setuptools.
Correct. Your choices are as follows: 1. get used to typing "setup.py egg_info" when you change your project's version number or entry points 2. write a script or alias to do it for you whenever you check your code in, or 3. reinvent the wheel so you can save a minute or two doing one of the above. If you choose #3, I sure hope it is because you're doing this for a hobby or personal project, because if you aren't, then you are defrauding your employer or client by diverting their funds for your personal enjoyment at wheel reinventing, while providing them with no additional benefits.
Phillip J. Eby wrote:
At 08:24 PM 12/8/2006 +0200, Ilias Lazaridis wrote:
Retrieving a few values directly from the setup.py (instead from an egg-info) would be fast and without any dependency.
In order to invoke run_setup to get the data, you must import, *at absolute minimum*:
distutils ...
I must read-in(!) at absolute minimum just the "setup.py" file, without any includes. ...
But for the 'light' needs, the overall overhead is (from my point of view) inacceptable.
That's because you're not paying attention to anyone's needs but your own. ... Thus, your view of the situation is extremely self-centered, ...
of course I look at my requirements. (whilst taking in account that others exist. thats btw. why I not say "drop those egg-infos")
As I've said, an ability to auto-generate egg_info if a setup.py is newer than the corresponding PKG-INFO might be a useful feature. However, trying to do without generating it at all, simply isn't going to happen. I understand.
Thus the only way to avoid "egg-info" is to avoid setuptools.
Correct. Your choices are as follows:
1. get used to typing "setup.py egg_info" when you change your project's version number or entry points
I've not choosen a dynamic language to do redundant steps. Otherwise I could pick java, which needs flagship-IDE's to stay managable. I like simplicity - that's why I am with python.
2. write a script or alias to do it for you whenever you check your code in, or
I do not provide automations, in order to manage redundant steps (only as a temporary solution)
3. reinvent the wheel so you can save a minute or two doing one of the above.
a minute or two, thousands of developers = many time.
If you choose #3, I sure hope it is because you're doing this for a hobby or personal project, because if you aren't, then you are defrauding your employer or client by diverting their funds for your personal enjoyment at wheel reinventing, while providing them with no additional benefits.
as said, from a user-level, I rate your work as _very_ helpfull. As a developer, I've mentione a deficit (from my point of view) and I just like to have some flexibility. I hope that a few other developers have a similar view and realize the need o "raw eggs" or "lightweight egg-based plugins", thus we can workout a solution. If anyone is interested, please contact me. This is a starting point, nothing else: http://dev.lazaridis.com/base/browser/infra/tracx/loader-draft-test.py?rev=1... The requirements as a whole: http://case.lazaridis.com/wiki/Package . -- http://lazaridis.com
At 09:22 PM 12/8/2006 +0200, Ilias Lazaridis wrote:
Phillip J. Eby wrote:
At 08:24 PM 12/8/2006 +0200, Ilias Lazaridis wrote:
Retrieving a few values directly from the setup.py (instead from an egg-info) would be fast and without any dependency.
In order to invoke run_setup to get the data, you must import, *at absolute minimum*:
distutils ...
I must read-in(!) at absolute minimum just the "setup.py" file, without any includes.
Then you are confused about how run_setup() works. run_setup() invokes the setup.py, which causes all of those modules to be imported. Perhaps you intend to instead parse the setup.py and figure out what it does from its syntax tree, without actually executing it? Good luck on that as well.
Phillip J. Eby wrote:
At 09:22 PM 12/8/2006 +0200, Ilias Lazaridis wrote:
Phillip J. Eby wrote:
At 08:24 PM 12/8/2006 +0200, Ilias Lazaridis wrote:
Retrieving a few values directly from the setup.py (instead from an egg-info) would be fast and without any dependency. In order to invoke run_setup to get the data, you must import, *at absolute minimum*:
distutils ...
I must read-in(!) at absolute minimum just the "setup.py" file, without any includes.
Then you are confused about how run_setup() works. run_setup() invokes the setup.py, which causes all of those modules to be imported.
I'm not refering to "run_setup".
Perhaps you intend to instead parse the setup.py and figure out what it does from its syntax tree, without actually executing it? Good luck on that as well.
You are speculating much to complex. Possibly during the long work on setuptools you've forgotten a few basic things: * python is very dynamic and expressive. * python is simple. * python stays simple, except you make things complex. - I have to sleep now. A good night (day) to all! . -- http://case.lazaridis.com/wiki/Package
Ilias Lazaridis wrote:
I have the following use-case:
within an application, i like to load several plugins from an folder, without any user-interaction
app/plugins/pluginone app/plugins/plugintwo
the plugins (standard sources prepared for setuptools, coming from svn) are arranged like this:
pluginone/one pluginone/setup.py #standard setup.py file
Is there any documented way to load such a "raw egg" (egg sources without a generated egg-info) into the application, without the need to generate the egg-info?
As a summary to this thread: I hope that a few other developers have a similar view and realize the need o "raw eggs" or "lightweight egg-based plugins", thus we can workout a solution. If anyone is interested, please contact me. This is a starting point, nothing else: http://dev.lazaridis.com/base/browser/infra/tracx/loader-draft-test.py?rev=1... The requirements as a whole: http://case.lazaridis.com/wiki/Package . -- http://lazaridis.com
participants (4)
-
Ilias Lazaridis -
Jorge Vargas -
Phillip J. Eby -
Ronald Oussoren