[TurboGears] Re: TurboGears2 installation failing on Mac OS 10.6.4 with python 2.6.1
On Aug 30, 1:28 pm, Christoph Zwerschke c...@online.de wrote: Am 30.08.2010 00:02 schrieb ozaycivelek: ImportError: cannot import name Method As Diez already answered, this sounds like you're installing TG1, not TG2, and running into the recent issue withpeak.rules. If you want to install TG1, then either install the oldpeak.rulesr2659 from here:http://files.turbogears.org/eggs/or wait 2-3 weeks, when there will be updates of TG 1.1.x and TurboJson which will work with the currentpeak.rules. Eek. I didn't realize this was causing people problems in production. I've just pushed out a snapshot that preserves the old imports, as a stopgap: http://peak.telecommunity.com/snapshots/PEAK-Rules-0.5a1.dev-r2686.tar.gz Sorry about that. -- You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turboge...@googlegroups.com. To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
[TurboGears] Re: problem installing TG 1.1 on ubuntu 10.04...
On Aug 13, 2:03 pm, Christoph Zwerschke c...@online.de wrote: Am 13.08.2010 10:57 schrieb nio: I'm new to TG and I'd like to install TG 1.1 on my xubuntu 10.04. I've followed the documentation steps, I've installed easy_install, virtualenv, activated my virtual_env, and then : easy_install TurboGears easy_install sqlalchemy But when I try tg-amdin info, here's what I get : frompeak.rulesimport abstract, always_overrides, Method, NoApplicableMethods ImportError: cannot import name always_overrides Hi Nicolas, sorry for your bad first impression. The problem is not with not using virtualenv or the Python version. TG 1.1 should work fine without virtualenv (even though it's recommended) and with Python 2.6. You've just chosen a bad day to try it out: The problem is caused by an API change in peak_rules made by Philip Eby just yesterday in r2660. It seems this change also broke the prioritized_methods package which is used by TurboJson. So the best fix for the time being is to install an older peak_rules version, e.gPEAK-Rules-0.5a1.dev-r2659.tar.gz which you can find here:http://peak.telecommunity.com/snapshots/ I will adapt TG 1.1 and 1.5 today so that it works with the new peak_rules packages and try to get prioritized fixed as well. Sorry about that - I'm trying to cleanly separate the API from the internals; always_overrides is internal, and should be imported from peak.rules.core, not from the parent package. I can stick always_overrides back in if this is going to be a widespread problem, but at some point it's got to go. If it helps, I could push ahead on supporting inline priority() in rules... ;-) (See http://dirtsimple.org/2010/08/simplifying-prioritized-methods-in-peak.html for details.) -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turboge...@googlegroups.com. To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
[TurboGears] Re: problem installing TG 1.1 on ubuntu 10.04...
On Aug 16, 5:01 pm, Phillip J. Eby p...@telecommunity.com wrote: I can stick always_overrides back in if this is going to be a widespread problem, but at some point it's got to go. If it helps, I could push ahead on supporting inline priority() in rules... ;-) (See http://dirtsimple.org/2010/08/simplifying-prioritized-methods-in-peak.html for details.) I went ahead and pushed out a new snapshot (r2672) with both a fix and the new priority() feature. Sorry again about the mixup. -- You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turboge...@googlegroups.com. To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
[TurboGears] Re: problem installing TG 1.1 on ubuntu 10.04...
On Aug 16, 6:17 pm, Christoph Zwerschke c...@online.de wrote: Am 16.08.2010 23:35 schrieb Phillip J. Eby: I went ahead and pushed out a new snapshot (r2672) with both a fix and the new priority() feature. Sorry again about the mixup. Thanks for the quick response, Phillip. I will use that feature in TurboJson then. -- Christoph By the way, I was just writing something for my blog about avoiding AmbiguousMethod errors *without* using priorities; I'm curious whether it might help you. I was actually writing it based on the one jsonify- like use case that I knew about that was causing ambiguous method errors, and I just took a look at how TurboJson is using priorities. Essentially, the issue is that you're putting what are basically your fallback cases in rules, instead of in the main method body. If you just put all your default cases in the main function body (instead of using @abstract), then those rules can't ever be ambiguous. But, if you *really* want to use rules to incrementally define your default cases, just define them on an abstract jsonify_default() function, then make a concrete jsonify like this: def jsonify(ob): return jsonify_default(ob) Voila... you now have the equivalent of your prio=-1 rules, while any rules defined on jsonify() itself will have higher priority, and *can't* be ambiguous with any of your default rules. Alternately, if the real issue is just conflicts with the lookup for '__json__', you can do this: @around(jsonify, hasattr(ob, '__json__')) def jsonify_explicit(obj): JSONify objects with explicit JSONification method. return obj.__json__() Then, you don't have to put in all those and not hasattr conditions everywhere else, because the explicit version will always take precedence if an object has the __json__ attribute. So, I guess what I'm saying is that PEAK-Rules has *always* had priorities -- they're just called putting the base cases in the body and use @around methods for things that need to take precedence over everything else. I'm wondering whether these would solve your problems without the use of priorities. -- You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turboge...@googlegroups.com. To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
[TurboGears] Re: problem installing TG 1.1 on ubuntu 10.04...
On Aug 16, 6:17 pm, Christoph Zwerschke c...@online.de wrote: Am 16.08.2010 23:35 schrieb Phillip J. Eby: I went ahead and pushed out a new snapshot (r2672) with both a fix and the new priority() feature. Sorry again about the mixup. Thanks for the quick response, Phillip. I will use that feature in TurboJson then. Just to be clear, I should mention that, now that I've seen what you're doing with it in TurboJson, the new priority() feature is *not* appropriate for that use case. That is, the new priority() does not allow you to define lower-than- normal priorities. Until now, it honestly never occurred to me that someone would need such a thing, since the One Obvious Way (but maybe not so obvious if you're not me!) to do that would be to put those rules in the main function body, or in a default cases generic registered as the default case of the user-facing function. -- You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turboge...@googlegroups.com. To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
[TurboGears] Re: problem installing TG 1.1 on ubuntu 10.04...
On Aug 16, 8:48 pm, Christoph Zwerschke c...@online.de wrote: Am 17.08.2010 01:33 schrieb Phillip J. Eby: So, I guess what I'm saying is that PEAK-Rules has *always* had priorities -- they're just called putting the base cases in the body and use @around methods for things that need to take precedence over everything else. Well, sometimes you still may want to have more levels of priority. Btw, you can also now make your own method-based priority levels as simply as: class MyLevel2(Method): pass when_level2 = MyLevel2.make_decorator() class MyLevel3(Method): pass when_level3 = MyLevel3.make_decorator() class Default(Method): pass when_default = Default.make_decorator() (Around, Before, After) MyLevel3 MyLevel2 (Method, MethodList) Default The '' operator on method types defines a partial ordering graph, though ordering is undefined between types you haven't explicitly shown a precedence for. So the above says that Around, Before, and After are higher precedence than all your new methods, and then those are higher than Method/MethodList, and finally default. (You could skip most of that if you just wanted to define a when_default for defining all your non-around defaults.) Regarding TurboJson, you're right though, the existing functionality should suffice and your ideas look like reasonable solutions to me. I'll probably try to change TurboJson to work along these lines you pointed out and see if I can get it done without breaking backward compatibility. Based on the mailing list posts I've been able to find, I think it will be backward-compatible; if not, please let me know what you find. Be sure to also see: http://www.eby-sarna.com/pipermail/peak/2010-August/003382.html If you haven't already. TurboJson was developed on rule-dispatch originally (which didn't have an around iirc), and later people probably only added upon that without really thinking about how to do it properly. Or *asking*, either. ;-) Your explanations and hints are highly welcome. It takes some time to get a feeling for how to adequately apply generic functions. Btw, while TG1 heavily relied on generic functions, TG2 does not use them any more and also recently ditched TurboJson. I guess the reason is that rule-dispatch and peak-rules can cause installation troubles, and people seem to have difficulties to wrap their head around generic functions generally. Maybe you need to do explain and advertize more ;-) Yes, I do. My recent blog post is a step in that direction; there will be more leading up to the first official release. -- You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turboge...@googlegroups.com. To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
[TurboGears] Re: jsonify and sqlalchemy support
On Nov 2, 5:29 am, Raphael Slinckx [EMAIL PROTECTED] wrote: Is there some kind of prioritization of dispatch method in case of ambiguous method ? Add an and condition that will be true to the higher-priority method. E.g. isinstance(x, Foo) and [some condition involving x that will be true]. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Packaging TurboGears and other required packages
Kevin Dangoor wrote: On 3/30/06, Simon Steele [EMAIL PROTECTED] wrote: Also, when installing do all the packages need to be placed under the system site-packages or is there a way I can place them locally with my installed TurboGears app? With recent versions of setuptools, I believe you can place the eggs anywhere on the PYTHONPATH. You can do this with any version of setuptools; the recent change is that such eggs can be used without needing require(), *if* you install them using easy_install. If you just dump them in a directory, you have to use require(). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Packaging TurboGears and other required packages
Kevin Dangoor wrote: Additionally, Phillip Eby provided this command a while ago: easy_install -axd tempdir YourPackage This will copy all of the required eggs from your system into the tempdir. With recent versions, you probably want -maxd, otherwise easy_install will complain that tempdir doesn't support .pth files. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Fixed that pesky autoreloader problem!
Don Hopkins wrote: The cause of the problem turned out to be some code in setuptools' pkg_resources module. The NullProvider base class (from which other providers like the EggProvider inherit) had an __init__ method that was grabbing the __file__ out of the module into fileName, assuming it was a path ending with the file name of '__init__.pyc', and calling os.path.dirname(filename) to get the directory name to import. When the __file__ did end with '.../__init__.pyc', it worked fine. But that would mysteriously change after reloads or exceptions! In the cases where it would crash, the __file__ actually contained just the DIRECTORY name without a trailing slash, instead of '.../__init__.pyc'. This is a bug in whatever code set or reset the __file__ attribute, not a pkg_resources bug. __file__ must be a filename or it must not exist. Presumably this is a problem in the code that's reloading the package in question. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Setuptools and proxies and cheetah in TG (oh my)
ajones wrote: Just a heads up to anyone trying to install 0.9 from behind a proxy, setuptools hates you. Specifically it uses a socket call to try and find a mirror to sourceforge, which fails if all of your network requests have to go behind a proxy. I poked around for a while and found no low hanging well documented fruit for another way of doing this, so I just made the offending function (get_sf_ip) return the domain name of a proxy instead. (easynews.dl.sourceforge.net for example). I know this is the wrong way to do it, but have no clue how the right way is supposed to happen. Well, unfortunately there's no computer-readable interface (that I know of) for obtaining SF mirror names other than the round robin DNS, so I just used a socket call to get the IP addresses so I could select a random mirror. The reason I did this is that on some platforms (Windows in particular), the DNS cache prevents round-robin DNS from working properly. So, if you just use 'dl.sourceforge.net' and get a bad mirror, the bad mirror stays stuck until the DNS cache is cleared, which meant that people could be unable to do any SF downloads, whereas with the round robin approach, they could just rerun their command to try a different mirror if the first one doesn't work. So, I guess what I could do is trap the socket error and fall back to the dl.sourceforge.net address. That's the only way I can see to avoid having to keep a hardcoded list of mirror names in there. It means, however, that if your proxy has a sticky DNS cache that doesn't do round-robin, you will still be out of luck if/when you happen to get a bad mirror. Anyways, two questions here. 1. Who do I get in contact with for setuptools to make them aware of this? The distutils-sig mailing list is the appropriate forum for setuptools discussion. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: TG, SQLObject, setuptools upgrade issue
Roman wrote: Hi all, Thank you. Finally it works. Yes, I had a 'http_proxy' variable in windows environment - but didn't remember that. But why didn't I have this problem when using easy_install for other thirdparty packages like cherrypy and kid? If they were installed from local copies, easy_install wouldn't have been fetching anything from the 'net, so the proxy setting wouldn't matter. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: problems with import pkg_resources
Gustavo Rahal wrote: I removed all the old installation and did it again $ python ./bin/ez_setup.py -f http://www.turbogears.org/download/index.html --install-dir ./lib/python2.4/site-packages/ --script-dir ./bin TurboGears Downloading http://cheeseshop.python.org/packages/2.4/s/setuptools/setuptools-0.6a9-py2.4.egg Download http://peak.telecommunity.com/dist/ez_setup.py and use that instead. It will install setuptools 0.6a10, which has much better configuration detection than 0.6a9. As long as the directory you're installing to is on PYTHONPATH, 0.6a10 will handle it correctly, whereas 0.6a9 requires you to follow the directions at: http://peak.telecommunity.com/DevCenter/EasyInstall#custom-installation-locations before you begin the installation process. 0.6a10 also has better error handling, so if there's still a problem with your setup after that we should know what it is. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: TG, SQLObject, setuptools upgrade issue
Roman Bischoff wrote: Hi Max, I'm still struggling with the SVN based installation. I've thought that the problem is solved with updating setuptools, which was ok. But it isn't :( I'm wondering why there seems to be a problem with the proxy in urllib2. There is no proxy - I've a direct internet connection. Any idea? Check your environment for a 'http_proxy' variable, or the registry under: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings for ProxyEnable and ProxyServer keys. These are what urllib uses to decide if you have a proxy. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: problems with import pkg_resources
Gustavo Rahal wrote: Hi elvelind Thanks for the reply. Well, I think setuptools is already installed: ls $HOME/lib/python2.4/site-packages/ [...] setuptools-0.6a10-py2.4.egg/ setuptools-0.6a9-py2.4.egg/ setuptools-0.6a9dev_r41857-py2.4.egg/ [...] There should also be a setuptools.pth file there containing one line, specifying the location of the 0.6a10 egg, and there should also be a site.py file in that directory as well. Last, but not least $HOME/lib/python2.4/site-packages must be in your PYTHONPATH environment variable. If you're missing any of these things, redo the installation and post the *complete* output of the ez_setup.py run so I can see what's happening. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: setting up errors setuptools (=0.6a9) not found
viyyer wrote: I have setuptools 0.6a9 installed output of dpkg -l|grep setuptools|grep 2.4 is ii python2.4-setuptools 0.6a9-1 Python Distutils Enhancements You might want to check to make sure there is a setuptools*.egg-info or setuptools*.egg file or directory present on your sys.path. If setuptools was packaged without an .egg or .egg-info, it will not work correctly, and the problem should be reported to the packager. In particular, there *must* be an .egg/EGG-INFO/entry_points.txt or an .egg-info/entry_points.txt file, or it won't work at all.
[TurboGears] Re: .pydistutils.cfg docutils wiki20 home directory failure
Daniel Holth wrote: Using easy_install to install anything in the system path (requiring root), for any reason, is not tasteful for me. Perhaps I am using a web host for which I do not have root. Perhaps I really need my eggs or anything else under /usr to be tracked in the system's package manager so that they can be easily deployed across many systems (and then uninstalled in the same way if they break) with my RPM package mangement tools. So I want to use per-user install of turbogears almost exclusively. See this section of the EasyInstall doc for details on how to do just about every custom installation scheme imaginable: http://peak.telecommunity.com/DevCenter/EasyInstall#custom-installation-locations It sounds like you may have set up something similar to the Administrator Install approach, but there are several others available for the different situations you describe, and the info may be useful to you in the future.
[TurboGears] Re: Obscuring decorators
Kevin Dangoor wrote: In order to introspect the function, we need direct access to it. I think the TurboGears decorators should all set an attribute on the function that has the original function object. That way, the decorators are a bit more flexible in terms of how they are arranged over the method in question. Opinions? Ideally *all* decorators would be true invariants. Unfortunately doing so would mean quite a serious rewrite (all except error_handler of course ;))). However I belive this is still the best solution in the long-run. Hmm... You're right. It would be nice for the decorators to be invariants or as close as possible to invariants. What would be nice is if the decorators actually maintained the signature of the functions they're decorating but added additional parameters as needed. I wonder how easy that would be? RuleDispatch's dispatch.on() and dispatch.generic() both have tools for generating functions that have the same signature as the original code. These deal correctly with both nested argument tuples and default values, so you might look there for examples of how to do it. Personally, for most decorators I just copy the function's __name__, __dict__, and __doc__ to the returned function, as doing the code generation is a bit of a pain for most decorator use cases.
[TurboGears] Re: No peak.security for 0.9
Kevin Dangoor wrote: On 1/22/06, Phillip J. Eby [EMAIL PROTECTED] wrote: Nowhere is there any mention of generic functions or adding methods or criteria, but it internally uses a Dispatcher object that does lookups based on class and attribute names. So, it's not necessary to expose generic functions' complexity directly, if all you want to do is define some type of registry of rules based on standardized access patterns. RuleDispatch was created in part because I got tired of having to write new kinds of registry classes all the time for PEAK, every time there I had some new way of looking things up. RuleDispatch lets me focus on the app and not on the data structures needed to implement it. I actually did consider identity.require registering rules in a context, but I couldn't see the value of doing that over just putting an expression in the call to require() and eval'ing it. It all depends on the complexity of the rules. For the use cases peak.security is intended for, where you have complex business rules to determine access, and evaluating those rules can result in SQL queries, you really want to make sure that the relevant tests are done at most once. If you're eval-ing multiple rules, you can't guarantee that without additional caching. For trivial rules, you're right that there's little additional benefit. PEAK is biased towards enterprise class business rules in this area, and the equipment shipping examples given in the peak.security docs are actually a *simplified* version of some business rules from a real enterprise application. The other benefit of course is indirection. Since permissions are separated from the authentication and authorization rules, it allows you to distribute an application component that can be customized without changing its source. The security rules are determined by context, not by hardcoding. It also allows you to avoid repetition, and encourages thinking about access control in terms of users and use cases rather than in terms of individual operations. And even if an application defines default permissions and rules, these can still be overridden in a particular deployment by subclassing the context and defining new operation-to-permission or permission-to-user rules. Anyway, these are not necessarily benefits for TurboGears' audience; I'm just pointing out for the sake of anybody following this thread what the intended benefits of peak.security are, so they can tell for themselves whether eval() is indeed better for *their* use cases. :)
[TurboGears] Re: install svn turbogears using python2.4 (while 2.3 is default)
Ksenia Marasanova wrote: Hi, Just wanted to check before breaking something :) i installed python2.4 on a Linux server with running applications that use python2.3. /usr/bin/python links to /usr/bin/python2.3, and I don't want to change that. Setuptools are not installed yet. Is there some setting that can be adjusted during installation of TG, so that setuptools will install everything using python2.4 binary? Just install setuptools using Python 2.4 explicitly (i.e., the python24 executable). This will make easy_install use Python 2.4 thereafter.
[TurboGears] Re: No peak.security for 0.9
Kevin Dangoor wrote: In this particular case, I think that the Identity user API is really easy to use and will meet a good variety of needs (but certainly not all). peak.security is the kind of thing that can meet everyone's needs, but wouldn't be as easy for some of the common cases that Identity is good at. Which is why RuleDispatch offers programmatic APIs for dynamically defining methods, so you can hide the details. Just because you *can* give unlimited flexibility, doesn't mean you can't have an easy API. For example, consider this command-line options framework: http://peak.telecommunity.com/DevCenter/OptionsHowTo Nowhere is there any mention of generic functions or adding methods or criteria, but it internally uses a Dispatcher object that does lookups based on class and attribute names. So, it's not necessary to expose generic functions' complexity directly, if all you want to do is define some type of registry of rules based on standardized access patterns. RuleDispatch was created in part because I got tired of having to write new kinds of registry classes all the time for PEAK, every time there I had some new way of looking things up. RuleDispatch lets me focus on the app and not on the data structures needed to implement it. As a practical matter, however, RuleDispatch's more advanced APIs are still alpha, which is to say they're likely to change significantly in the future as I refactor to allow new features and improve the current speed/space tradeoffs. With the limited time I have to work on it, I'm not sure how long it will be before any of these things can get done.
[TurboGears] Re: top-level __init__.py created by quickstart
Max Ischenko wrote: Hi, When creating new project with quickstart it creates __init__.py in top-level directory. This is a bug or I'm missing something? Sounds like a bug to me; such a project wouldn't be usable with setup.py develop.
[TurboGears] Re: Downloading all dependency eggs into a directory
Karl Guertin wrote: On 1/16/06, Michele Cella [EMAIL PROTECTED] wrote: By the way this only works for the stable release, but I think you were talking about the TG svn. :-( Indeed I was, that's how I did it last time when I was using the stable release. I wound up just copying all the .egg files in my site-packages over to a temp dir and deleting all the ones that weren't needed. The '--always-copy' or '-a' option to easy_install will copy all needed eggs to a given directory, so something like this will work on a machine that has all the eggs already: easy_install -axd tempdir TurboGears (The -x is short for --exclude-scripts.) Anyway, this will basically just dump all the eggs you need in one directory for you, with no manual fiddling required. You can then copy them to the other machine and use -f to find them.
[TurboGears] Re: Installing turbogears from a file...
ajones wrote: Downloaded the eggs from turbogears.org/download/ (had to get setuptools from the cheeseshop as the download page had a development version) Modify ez_setup.py so that DEFAULT_URL pointed to file:C:/path/to/download/directory/ Run ez_setup.py like normal using -f c:/path/to/download/directory/ Why the need to specify this location in two different places? I am assuming that the -f argument indicates the file source, if so why does the system seem to use DEFAULT_URL exclusively? ez_setup.py is a bootstrap script used to install setuptools only. It has extremely limited intelligence and is mainly intended to be imported by a setup script (i.e., a setup.py file). As you will see from the docstrings, a script can call use_setuptools() with a different default URL and version. Anyway, it is designed only to download a setuptools egg from a known absolute URL, and then pass command-line arguments on to easy_install once setuptools is bootstrapped. The normal way to use a setuptools egg you've already downloaded with ez_setup.py would be to just put the egg in the current directory. ez_setup.py detects when the requested version of the setuptools egg is present in the current directory, and will use it without downloading. In other words, you're trying too hard. :) Just put the setuptools egg in the current directory and run ez_setup.py. DEFAULT_URL is used *only* to download the setuptools egg, and it has nothing whatsoever to do with -f/--find-links; it does not work in the same way at all. -f is used for *finding* things without a known download URL, and the code that does that is in the setuptools egg; ez_setup.py doesn't have that code or all the other easy_install features built in, because then it would be as big as setuptools itself. :) It just *seems* to have those features because once setuptools is bootstrapped, it passes the command-line arguments on to easy_install.
[TurboGears] Re: SVN install still looking for python 2.1.1
Kevin Dangoor wrote: And I've confirmed with Phillip that I can't conveniently put up an egg of CP 2.2 unless I hide it away in some other part of the TurboGears site. Well, you could change all the 2.1 dependencies to be =2.1,2.2a which would reject any 2.2 alphas or betas as well as 2.2 itself. That might not be *convenient*, of course. :)
[TurboGears] Re: Permission denied: '/.python-eggs'
mtg wrote: Moin, I use some components from the tg installation for scripts. Sometime I've got: OSError: [Errno 13] Permission denied: '/.python-eggs' Your HOME appears to be set to '/' instead of your home directory, causing the attempt to create a cache directory to fail. Correct your HOME environment variable, or set a PYTHON_EGG_CACHE environment variable to a subdirectory owned by you, such as /home/yourlogin/.python-eggs.
[TurboGears] Re: build an egg from svn turbogears/thirdparty/cherrypy
[EMAIL PROTECTED] wrote: if your just trying to make it work just go to the cherrypy dir and run: easy_install cherrypy Actually, that would be 'easy_install .' if the current directory has a setup.py in it. In general, if you want to build an egg for a package that doesn't use setuptools, you can use: easy_install -zmxNd target_dir source_dir_or_requirement Where 'target_dir' is the directory the egg will be copied to, and 'source_dir_or_requirement' is either the directory of the setup.py, or a PyPI requirement (e.g. CherryPy=2.1). The '-zmxNd' is -z (keep the output zipped), -m (multi-version, i.e. don't update a .pth file), -x (exclude scripts), -N (no-deps, don't build any dependencies), -d (set installation/target directory). You can actually specify multiple source_dir_or_requirement, which is handy if you want to automate building a bunch of eggs from PyPI or some such.
[TurboGears] Re: do not your projects after TG components
Cliff Wells wrote: nerkles wrote: True it's a programming error, but it wouldn't hurt anything to have quickstart do an idiot-check on the name you give it. There are a lot of modules/components in Python, and quite a few components to TG itself that a new user/developer might not remember or even know about--either somebody new to Python and/or to TG. There will probably be a lot of people who are learning Python and TG at the same time. It would be helpful for the overall user experience if the thing called quickstart prevents you from creating a mess like that your first time out. Imagine a stream of errors being your first taste of TG! Most people would give up on it right then. And it wouldn't be difficult to implement. Perhaps a simple: try: p = __import__(projectname) assert False, That name is already taken by an installed module except ImportError: pass Actually, it would need to be a bit more sophisticated than that, since it's a clash in project names, not module names that was the issue here. Something like: env = pkg_resources.Environment() if projectname in env: print projectname, is already in use by, for dist in env[projectname]: print dist; break Also, it'd be good to check PyPI for a matching name registration, but that's a bit more complex. The setuptools.package_index module can do it fairly easily, but it's slow due to needing to read the entire index in order to do case-insensitive matching. And of course it requires internet access.
[TurboGears] Re: if you're running from svn...
Kevin Dangoor wrote: On 1/6/06, Bob Ippolito [EMAIL PROTECTED] wrote: python setup.py develop worked fine here, with no explicit installation step for TurboKid. That's odd. I could swear that people had trouble getting stuff to install via setup.py develop just a few days ago. Oh yes... I think the difference is that those eggs were not in PyPI whereas TurboKid is. FYI, as of setuptools 0.6a9, you can set [easy_install] find_links in setup.cfg and they will be honored by the develop command. So you should be able to get this to work okay even for stuff that's not in PyPI.
[TurboGears] Re: Identity now supports richer requirements checking
Kevin Dangoor wrote: On 12/27/05, Jeff Watkins [EMAIL PROTECTED] wrote: Many people wanted something more flexible, and with revision 400, any of the following are valid require decorators: @identity.require( in_group( admin ) ) @identity.require( in_all_groups( admin, editor ) ) @identity.require( in_any_group( admin, editor ) ) @identity.require( has_permission( edit ) ) @identity.require( has_all_permissions( edit, delete, update ) ) @identity.require( has_any_permission( edit, delete, update ) ) But most importantly, you can use decorators like theses: @identity.require( Any( in_group( admin ), has_permission ( edit ) ) ) @identity.require( All( from_host( 127.0.0.1 ), has_permission ( edit ) ) ) @identity.require( All( from_any_host( 127.0.0.1, 10.0.0.1 ), in_group( editor ) ) ) This is cool. I wonder, though, if there's a way we can do this by getting RuleDispatch in the mix. RuleDispatch is *very* fast and flexible. See also: http://peak.telecommunity.com/DevCenter/SecurityRules which is an access control rules library based on RuleDispatch. The source code for the module (less than 200 lines!) is here: http://svn.eby-sarna.com/PEAK/src/peak/security/rules.py?rev=1978view=markup If you lop off the interface declarations and the 'binding'-decorated functions at the end of it, the code will not introduce any PEAK-specific dependencies except for RuleDispatch. (Heck, if you want, I could just as easily spin this off into its own egg.) Note that it would still be possible to use the existing @identity.require() helpers, they could just translate to expression strings that would get passed to RuleDispatch under the hood.
[TurboGears] Re: Modules - Is this the way it is?
Elvelind Grandin wrote: accually no. it seemed scary to try that. I dont want to clutter up PyPI with stuff thats not meant to be there. Well, if it doesn't work, there won't be a problem. ;-) On the other hand, if it does work, you can just click on the big Remove this package completely button afterwards. :) To get to the PyPI web interface, just go to any PyPI page and click on Login and log in. You'll then have a list of your registered packages in the sidebar. Click on the one you want to remove, and there'll be a nice big button at the top of the edit screen.
[TurboGears] Re: EntryPoints [was: shopping cart and catalog system]
Jeff Watkins wrote:
Can anyone point me to a quick example of how this actually works?
I've looked at the setup tools web site, but I didn't understand it.
Someone's already mentioned TurboGears' setup script. Here are a few
other links with examples:
http://groovie.org/articles/2005/09/29/setuptools-and-python-paste
http://pythonpaste.org/script/developer.html
Neither of these really explain from the point of view of the person
who's trying to create a system of plugins, though. I'll try and give
a brief explanation.
Entry points let you do simple plugins. If you want to have some kind
of plugins (like Turbogears' widgets), you simply come up with a unique
name for an entry point group that will identify what kind of plugins
they are. You need this name because entry points can be used for lots
of things and this lets you distinguish your application/framework's
entry points from those belonging to others. Let's say you decide to
call your group 'turbogears.widgets' (the name has to be a dotted
Python identifier).
Now, in your application, you would use the EntryPoint API:
http://peak.telecommunity.com/DevCenter/PkgResources#entry-points
in order to look up the entry points that people have provided in their
eggs, that are in that group. In the simplest example, you could do
something like this:
for ep in pkg_resources.iter_entry_points('turbogears.widgets'):
print Found widget, ep.name, from, ep.dist
This will print a list of things like Found widget foobar in
SuperTGWidgets-1.2. Each entry point object has a load() method that
will return whatever the entry point was registered as. So for
example, you could have people register their widget classes in their
eggs' setup.py scripts, and then when the eggs are installed, their
entry points will show up in the list automatically.
That's really all there is to it - it's a way for a plugin to
advertise a Python object it has, under an agreed-upon group name,
for applications or frameworks to find, import, and plug in. The
rest is mostly details.
You need to give each individual entry point a name, not just the
group. The meaning of this name depends on what you're doing with it.
For setuptools commands and tg-admin commands, the name is what you
type on the command line to run that command. For other applications,
the name might be ignored, or it might be the name of a keystroke
combination that will activate a command in an editor. Or the name
might be just used to identify the entry point in other configuration
files, to enable optional features or plugins.
So, there's not much to entry points, really. It's all in how you
decide to use them. By themselves, they're sort of like files and
directories - if you had a convention for how to organize plugins,
they'd be useful. If you don't know what you want to do with plugins,
it's just an empty box with nothing to put in it.
[TurboGears] Re: setuptools is going crazy on latest SVN 0.9a0dev-r341 (on windows)
[EMAIL PROTECTED] wrote: Downloading http://effbot.org/downloads/index.cgi/cElementTree-1.0.5-20051216.zi p?index error: Unexpected HTML page found at http://effbot.org/downloads/index.cgi/cElementTree-1.0.5-20051216.zip?index I follow the output and it should jump to that URL without the ?index although that is on the source and it's a valid html page as the output says, and it has a link to the actual zip file. I think this may be a bug in setuptools parser, but i have no idea how that works so I can't really tell. This is an old bug, fixed some time ago. Upgrade setuptools using: ez_setup.py setuptools==dev (and including --script-dir=/usr/local/bin before the setuptools==dev part if that's where your easy_install is.)
[TurboGears] Re: setuptools is going crazy on latest SVN 0.9a0dev-r341 (on windows)
[EMAIL PROTECTED] wrote:
that is really weird, i am doing a clean install on this machine.
I got dev version of (setuptools now =0.6a9dev-r41761)
I got pass element tree and PasteScript but failed at json-py
Processing dependencies for TurboGears==0.9a0dev-r341
Searching for json-py=3.2.1
Reading http://www.python.org/pypi/json-py/
Couldn't find index page for 'json-py' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://www.python.org/pypi/
No local packages or download links found for json-py=3.2.1
error: Could not find distribution for
Requirement.parse('json-py=3.2.1')
it is true the URL doesn't exist anymore, the new URL is
http://www.python.org/pypi/python-json I changed it in setup.py but it
still couldn't find it
Processing dependencies for TurboGears==0.9a0dev-r341
Searching for python-json=3.2.1
Reading http://www.python.org/pypi/python-json/
Reading http://sourceforge.net/projects/json-py/
No local packages or download links found for python-json=3.2.1
The PyPI page for this project doesn't include any direct download
links, nor does it include a home page or download URL with links to
the package. Please ask the author if they would change their download
URL to point to a page with direct download links, such as their
sourceforge files page, e.g.:
http://sourceforge.net/project/showfiles.php?group_id=137891
EasyInstall isn't a general-purpose web spider; it only scans for links
on PyPI pages, plus the home page and download URL listed on PyPI.
This keeps it from wandering all over the web looking for packages. :)
In the meantime, I'd suggest you use the -f or --find-links option to
easy_install to supply the missing URL, e.g.:
easy_install -f
http://sourceforge.net/project/showfiles.php?group_id=137891 json-py
Oh, wait, that doesn't work, because the author didn't include a
setup.py. Not only that, the PyPI listing is for python-json, even
though the project name is json-py.
Okay, so json-py's distribution is completely fouled up. The only way
it's going to work with easy_install is if:
1. It gets a setup.py
2. It gets registered with the its *own* name on PyPI
3. It has a link from PyPI either directly to downloadable files or to
a page with links to downloadable files.
Either that, or somebody else needs to create their own packaging of
this with another name, that fixes the above three issues. Or, maybe a
switch to Bob Ippolito's simple_json is in order? His package is
actually downloadable from PyPI as source or eggs.
I know Kevin has a json-py packaging on turbogears.org; it would
probably be a good idea for him to either rename it and put up a PyPI
listing, or ditch it and go with a package that at least uses the
distutils.
[TurboGears] Updated installation instructions for EasyInstall/setuptools
I just checked in (and updated on the Wiki) the installation instructions for setuptools and EasyInstall to cover a lot of frequently-asked questions and problems (e.g. how do I install without net access?), as well as to explain additional approaches to custom installation locations. The new docs on custom installation are at: http://peak.telecommunity.com/DevCenter/EasyInstall#custom-installation-locations And the main installation instructions, now with better troubleshooting and alternatives information, is at: http://peak.telecommunity.com/DevCenter/EasyInstall#installation-instructions Please let me know whether these are more helpful than the old versions. I've also added a new section to the setuptools manual called What Your Users Should Know: http://peak.telecommunity.com/DevCenter/setuptools#what-your-users-should-know This section provides developers using setuptools with notes on what they should tell users about installing their project -- such as that they should read the custom installation docs if they plan to install anywhere but the primary site-packages, and tips on issues ranging from system packaging (0.6a9dev+ only) to lack of network access. Feedback on this new manual section would also be appreciated. There is only one more feature I'm planning to add before the official release of setuptools 0.6a9: support for building and installing shared libraries linked to Python extensions. If you are not using the 0.6a9 development version yet, I encourage you to upgrade as soon as practical so that I can address any problems you find before making the official release. To install the in-development version, just run: ez_setup.py setuptools==dev after first making sure you have done any pre-installation steps described by the updated installation instructions above. Thanks, and please let me know of any questions or problems you may have with any of the above.
[TurboGears] Re: TypeError: swig_sources() takes exactly 2 arguments (3 given) - with fc4 and cElementTree
Kevin Dangoor wrote: On 12/14/05, Phillip J. Eby [EMAIL PROTECTED] wrote: By the way, Kevin, maybe it's time for you to bump the version of ez_setup you're distributing? A lot of commonly-reported installation problems on the list lately are ones that were already fixed by more recent versions of setuptools. (E.g. elementtree download on effbot.org, the above issue, SourceForge processing, Subversion support, '-rc' release numbers, etc. etc. etc.) I had been waiting for a release to bump the version (from what I see, 0.6a8 is still the latest version). It looks like I can't just pick up the ez_setup.py from svn, because it gets a 404 when looking for 0.6a9. Or are you suggesting that I tell people to run ez_setup.py seutptools==dev? You have fixed a bunch of things that have been bugging people, so I would like to do the right thing in getting an update going. Put this in your setup.py: from ez_setup import use_setuptools use_setuptools(0.6a9dev_r41701, http://turbogears.org/download/eggs;) and build an egg for the corresponding version of setuptools and put it in the download/eggs directory. See also the docstring for 'use_setuptools()' in ez_setup.py. (Note, however, that you may need to keep the eggs around for a while, in case somebody tries to install from an older source release of TurboGears. The download process simply tries to directly fetch the egg, it doesn't have any smart page parsing or version checking, since all the smart stuff is in pkg_resources and setuptools.package_index, which of course haven't been downloaded yet. :) )
[TurboGears] Re: TypeError: swig_sources() takes exactly 2 arguments (3 given) - with fc4 and cElementTree
Phillip J. Eby wrote: Put this in your setup.py: from ez_setup import use_setuptools use_setuptools(0.6a9dev_r41701, http://turbogears.org/download/eggs;) Oops; that needs a / on the end, i.e. http://turbogears.org/download/eggs/. It says that in the docstring for use_setuptools(), but I wasn't paying attention. :)
[TurboGears] Re: Linux Installation Issues
[EMAIL PROTECTED] wrote: Hi Phillip, I tried what you suggested and it still hangs at the download stage for a very long time. How long is a long time, and did you have net access to turbogears.org at the time? I presume from what you attached that the pause was while downloading the turbogears .egg?
[TurboGears] Re: TypeError: swig_sources() takes exactly 2 arguments (3 given) - with fc4 and cElementTree
[EMAIL PROTECTED] wrote: I have been trying on and off for awhile to get TurboGears installed on my fedora core 4 system with python version 2.4.1 Running python ez_setup.py -D -f http://www.turbogears.org/download/index.html --script-dir /usr/local/bin TurboGears it would fail installing cElementTree-1.0.2-20050302 with the error TypeError: swig_sources() takes exactly 2 arguments (3 given) This is a Pyrex problem; more recent versions of setuptools include a workaround for the issue. By the way, Kevin, maybe it's time for you to bump the version of ez_setup you're distributing? A lot of commonly-reported installation problems on the list lately are ones that were already fixed by more recent versions of setuptools. (E.g. elementtree download on effbot.org, the above issue, SourceForge processing, Subversion support, '-rc' release numbers, etc. etc. etc.) Even if you end up with something less stable, I'll at least have *new* bugs to troubleshoot instead of the same already-fixed ones over and over. ;-)
[TurboGears] Re: Offline Install?
Jorge Vargas wrote: I'm trying to install TG at work, and the firewall is blocking the python scripts, i can download the files manually (i did that with setuptools) and hacked the scipt to read the file from my disk, but now it's downloading TG, so I think I should ask for help instead of keep messing up. Can I a) download all the files and tell the scripts paths to them? Yes; download them to a directory, go into that directory and use -f. as in: ez_setup.py -f. TurboGears By the way, there is also a proxy server available at http://ntlmaps.sf.net/ that lets Python get through NTLM-based firewalls in the same way that your web browser does; you just have to run it and configure urllib to use it as a proxy server.
[TurboGears] Re: Offline Install?
[EMAIL PROTECTED] wrote: which is the exact list of packages? all the ones listed in http://turbogears.com/download/index.html is that list up to date for 0.8 that is? I'm not sure which cElementTree file to get (i'm running windows here) should i get ElementTree + win32 or ElementTree + modified one? For Windows, I don't believe you need any source packages; just get .egg and -win32.egg files. Note, however, that if you get more than you need, or less than you need, it's not a problem. If you're missing something, the install process will fail, but can safely be restarted once you download the missing thing. When you rerun the same command, it'll only look for things it hasn't already installed.
[TurboGears] Re: Old TurboGears eggs
Wavy Davy wrote: Yeah, I tried that, but it didn't work. A according to to the easy_install help it only deletes conflicting packages. The old ones are still there. Sounds like functionality yet to be implemented... Correct; I'll be adding a 'nest' tool for package management during the 0.7 series, and it will eventually include a garbage collection tool to get rid of unused eggs.
[TurboGears] Re: svn checkout fails to find cElementTree (and PasteScript)
m h wrote: My bad, that was using easy_intall-script.py. Using ez_setup.py I it appears to work... (Is that a bug in easy_install-script.py? Shouldn't they be doing the same thing?) In principle, yes; in practice, Windows has trouble upgrading files that you are currently running; that's why if you're upgrading setuptools on Windows, it's better to use ez_setup.py (since it's not changed by upgrades). I hope to have a fix for this issue, but it's probably still weeks away as I've got quite a backlog of other issues for setuptools. :(
[TurboGears] Re: svn checkout fails to find cElementTree (and PasteScript)
m h wrote: Hmmm, I commented out the requirement for json in setup.py and ran python setup.py develop again. It's failing on Kid now with a Sandbox violation. Kid tries to import its dependencies in its setup script, before installation has even occurred. This is, uh, well, seriously broken, because by definition your package isn't ready to run if isn't installed yet, and its dependencies aren't going to be there. It would be good if someone could pass that info along to the Kid maintainers. Kid's setup script tries to import kid during setup in order to find out what version it is and some other stuff. There's a safer, saner way to do that, though; the recently-added PyPI project networkx has a good example in its setup script using execfile() instead of import in order to get at that data without actually importing the package and its dependencies. Anyway, I do plan a workaround for the issue that's creating the sandbox violation in Kid, but there's no way for me to work around the essential brokenness of trying to import dependencies before they're installed. :(
[TurboGears] Re: svn checkout fails to find cElementTree (and PasteScript)
m h wrote: sorry about the spam (if this is a known issue)... I updated setuptools and re-ran python setup.py develop and now get the following: C:\Documents and Settings\Administrator\Desktop\matt\turbogearspython setup.py develop running develop running egg_info writing requirements to TurboGears.egg-info\requires.txt writing TurboGears.egg-info\PKG-INFO writing top-level names to TurboGears.egg-info\top_level.txt writing entry points to TurboGears.egg-info\entry_points.txt writing manifest file 'TurboGears.egg-info\SOURCES.txt' running build_ext Creating c:\program files\python23\lib\site-packages\TurboGears.egg-link (link t o .) TurboGears 0.9a0dev-r286 is already the active version in easy-install.pth Installing tg-admin-script.py script to C:\Program Files\Python23\Scripts error: c:\program files\python23\lib\site-packages\setuptools-0.6a9dev_r41617-py 2.3.egg\setuptools\cli.exe: No such file or directory That's weird. It looks like your setuptools installation is missing some files. I also notice you're using Python 2.3, which TurboGears doesn't support, but setuptools should. (I do most of my development and testing of setuptools using Python 2.3 on Windows, so I'm *really* surprised by the above.) Did you get any error messages when you updated setuptools? What's weird to me is, is that if the file shown were missing, then it seems to me that installing setuptools should've given you the exact same error.
[TurboGears] Re: install 0.9 using easy_install?
Lee McFadden wrote: Installing directly from SVN via easy_install isn't possible at the moment. Not true, you just need to use an SVN url with a #egg=TurboGears suffix. The exact incantations are in the setuptools manual. It'd be something like: easy_install -f 'svn://somewhere/blah/trunk#egg=TurboGears' TurboGears Substituting the right svn: or http: URL, of course. You should probably also include the URL of the TurboGears download page in the -f argument, so as to pick up the dependencies. The only reason you can't just do easy_install TurboGears==dev the way you can with setuptools is that Kevin hasn't put an #egg=TurboGears-dev subversion link in his PyPI page, like the one setuptools has.
[TurboGears] Re: svn checkout fails to find cElementTree (and PasteScript)
m h wrote: I don't recall any strange error message. Ummm, what is the best way to uninstall and start over? Just delete the egg directories? Yes. But ez_setup/easy_install will overwrite the eggs and ignore older ones anyway, so there's no need to manually delete them. Anything else? Or would you recommend another route? No; I'd suggest reinstalling using 'ez_setup.py setuptools==dev'. Then we can check and see if your installation has the cli.exe file. If the problem persists, I'll have to figure out some other way to proceed with debugging this. When I install setuptools on my own machine, this problem doesn't occur.
[TurboGears] Re: Upgrading to 0.8a5 doesn't upgrade CherryPy
Kevin Dangoor wrote: Phillip has changed how setuptools interprets version numbers to catch stuff like rc's and betas. Not exactly. What I changed is that setuptools always interpreted a '-' as indicating a post-release patch. This meant that if you put a '-' before 'rc' or 'beta' or whatever, it was still considered a *post*-release, which caused all the CherryPy upgrade problems. Setuptools always interpreted numbers like '2.1.0rc2' or '0.2b5' correctly; it was only the inclusion of a '-' that threw it off. Now, the '-' is ignored if it precedes something that would otherwise be considered a pre-release like 'rc' or 'b'. Note that this means that using the very latest (i.e. today's version, 0.6a9dev-r41630) setuptools (ez_setup.py setuptools==dev) is necessary if you're upgrading CherryPy or trying out the new Subway release, as both have the problematic '-rc' versions out there. When CherryPy did it, I sort of assumed it was a fluke. When Subway did it too, it made it abundantly clear that the dash-is-postrelease logic was not intuitive, and I had a flash as to how I could fix it in a way that hopefully won't break anything else. :)
[TurboGears] Re: hardcoded paths in tg-admin.exe and easy_install.exe?
[EMAIL PROTECTED] wrote: Sure, here's the error message from within a Win Command Prompt: easy_install TurboGears C:\Program: can't open file 'Files\Python2.4.2\python.exe': [Errno 2] No such file or directory My Python install is under C:\Program Files\Python2.4.2\, so this error message is just like the one seen before when trying to run tg-admin; that space in the path seems to cause the trouble. Thanks for your help. Hm. Try typing easy_install setuptools, and tell me the exact version of setuptools it says is installed. I've tried to reproduce the failure with the latest version and so far have not been able to. I'm using a different path with a space in it, but it seems to me any path with a space should still work. Are you also positive that it's a *new* tg-admin.exe, and that it's installed in the directory that you think it is in?
[TurboGears] Re: Trying to setup a turbogears development version
slate wrote: Kids egg is not working. I solved this problem by downloading kids source. I made an egg with setup.py, and installed this on my computer. FYI, the issue is that kid's setup.py actually imports kid at the beginning, and kid's initialization code imports ElementTree. This is broken, since until the setup actually runs to completion, there may not even *be* an ElementTree package installed. And if you *do* have ElementTree installed, it may need to extract a resource from that egg, which then causes the SandboxViolation. I do plan to make the SandboxViolation be ignored when it's pkg_resources doing the violating, but that won't fix the fundamental brokenness of a package trying to import its dependencies from within its setup script. :( By definition, when a setup script is running, the code is *not installed yet*. In general, then, it's an extremely bad idea to import code from your project inside your setup script. Some of the recent dependency problems with the TurboGears quickstart were indirectly caused by the exact same issue (i.e., importing TurboGears inside a setup script, when Turbogears was a requirement of the project, but not yet require()d by setup_requires). Unfortunately, because the author's machine already has everything set up the way they want it, they don't notice any problems from this kind of code. I wish there were some way to warn package authors about the issue. Maybe I should have setuptools output a warning when setup() is called, if any of the modules or packages that are listed for installation have already been imported from the source directory. That would help dispel the illusion that the setup will still work correctly when the package is distributed. Ideally, I suppose it should also check for any imports coming from dependencies listed in install_requires, or maybe just any non-setuptools, non-stdlib imports, except for non-distributed modules or packages in the setup directory. That does seem a bit draconian, though.
[TurboGears] Re: toggling between 0.8a4 and 0.9
qvx wrote: I have 0.8a4 installed. I also have latest svn snapshot in some custom directory. What is the easiest way to switch between those two versions? To select the svn snapshot, cd to it and run ./setup.py develop. To select 0.8a4, run easy_install TurboGears==0.8a4. If you are installing scripts to /usr/local/bin, make those: ./setup.py develop --script-dir=/usr/local/bin and easy_install --script-dir=/usr/local/bin TurboGears==0.8a4 respectively. Both of these commands work by updating easy-install.pth to include the needed packages, and overwriting the current scripts with wrappers for the selected version. (Note that the ==0.8a4 part is needed so that easy_install doesn't see the installed 0.9 development version and decide that's the best matching version.) Neither of these commands will reinstall anything but the .pth and scripts, unless you've updated the Subversion edition and it wants a newer dependency of something.
[TurboGears] Re: [Distutils] problems installing elementTree
At 01:15 PM 11/26/2005 +, Sharky On PTNet wrote: Hi, I'm getting problems instaling Turbogears when easy_install try to install cElementTree. I have ubuntu breezy (5.10) with python 2.4.2. Any one can helpme with this? I've just checked in a fix. The problem was that the effbot.org pages contained links that look like download links (because they include cElementTree-1.0.2-20050302.zip as the last path part), but which are actually links to a CGI that lets you view the *contents* of the zipfile, as an HTML page. The way that EasyInstall was sorting candidate links was causing it to prefer longer links over shorter ones, assuming that the two links appeared to be pointing to the same package, version number, and format. I've now changed it to prefer shorter links over longer ones, assuming all else is equal. And I've verified that this makes it ignore the effbot.org CGI links and prefer the real download links. You can upgrade your EasyInstall using: easy_install setuptools==dev this will upgrade you to the latest revision from Subversion. (Note: Windows users, please use ez_setup.py setuptools==dev, as easy_install.exe isn't currently able to updgrade itself without permission problems.)
[TurboGears] Re: easy_install need be improved
[EMAIL PROTECTED] wrote: easy_install only solve the problem about python package dependency.it is difficult to use. after check out from turbogears svn,i use python setup.py install, but often have many error messages,and i only use easy_install each package manually. There's an outstanding patch opportunity to fix this issue; google for dependency_links to find notes on it. and when easy_install can remove the packages automaticly?removing package is very inconvenient. In the 0.7 series, there will be a more sophisticated package management tool, tentatively called nest that will offer features like nest list to show installed packages, nest rm to delete, etc. This is still in the planning stages and the design isn't final yet. There are also discussions under way to get eggs better integrated with system packaging tools like Gentoo, Debian, RPM, etc., and in fact if you use Debian already the easy_deb tool can make eggs into .deb packages that can be managed by the local tools. Similarly, there is another experimental wrapper for Gentoo. So, depending on the packaging system you use, you may have some other options as well here.
[TurboGears] Re: Install from SVN issue
Scott Benjamin wrote: I did as Kevin suggested yet the error continues to come back when running python setup.py install . What is the preferred method of installing an SVN version of turbogears? I would suggest that you use a manual checkout and run setup.py develop, rather than setup.py install. Install builds and installs a new egg every time, but develop just links your checkout to the Python path so that any updated versions will run from there. Also, develop respects the --find-links option in the setup.cfg, so it should be able to find TurboGears' dependencies better than install does. Is there a doc anywhere that can be referenced? I suggest these two sections of the setuptools manual: http://peak.telecommunity.com/DevCenter/setuptools#managing-continuous-releases-using-subversion http://peak.telecommunity.com/DevCenter/setuptools#develop-deploy-the-project-source-in-development-mode
[TurboGears] Re: jsonify an SQLobject with TG-rev226
william wrote: I've switched from MySQL-4.0.24 (mysql-python-1.2.0) to Postgres-8.0.3 (psycopg-1.1.5) and the problem disappears. If someone understand ??? Looking at the error messages, it appears that jsonify doesn't know what to do with the Python long type. My guess is that your change in database affects whether integers returned from the database are ints or longs. Looking at Ian's original jsonify source code at: http://svn.colorstudy.com/home/ianb/rule_dispatch/jsonify.py I see that it does not in fact provide any jsonification method for the Python long type. Perhaps someone can contribute one.
[TurboGears] Re: how to upgrade tg-admin
Ksenia Marasanova wrote: 2005/11/19, Lee McFadden [EMAIL PROTECTED]: It sounds like a path issue. Run sudo python setup.py develop again and scroll through the output. It will tell you where it's putting the tg-admin for version 0.9adev-rxxx. Thanks, it was indeed path issue. It appears that I have two version of tg-admin: 0.8x version: /usr/local/bin/tg-admin 0.9x version: /Library/Frameworks/Python.framework/Versions/2.4/bin/tg-admin You need to include --script-dir=/usr/local/bin on your setup.py develop line if you want the scripts to go to /usr/local/bin. Otherwise, they go to the default installation location for Python scripts on your computer. i.e.: setup.py develop --script-dir=/usr/local/bin
[TurboGears] Re: SVN VersionConflict on tg-admin sql command
Lee McFadden wrote:
pkg_resources.VersionConflict: (TurboGears 0.9a0dev-r223 (c:\svn\turbogears),
Re
quirement.parse('TurboGears=0.9a0'))
--/Traceback--
It looks like setuptools isn't recognising the fact that 0.9a0dev-r223
0.9a0.
That's because 'dev' is a pre-release tag, not a post-release tag.
0.9a0dev means the 'dev' pre-release of 0.9a0. Thus, if you want to
include all dev releases in your requirement, you need to say
TurboGears=0.9a0dev
I remember something along these lines occuring before on
this mailinglist, but I can't pin down the thread.
I've updated the in-development setuptools manual at:
http://svn.python.org/projects/sandbox/trunk/setuptools/setuptools.txt
to include a new section called Specifying Your Project's Version
(which you can search for in that file) which gives a detailed
explanation of the pre-release and post-release tags that setuptools
understands, along with its interpretation of the numeric parts of a
version number. It even tells you how to test your version numbering
scheme by typing simple expressions at the Python prompt. Hopefully,
this will help the situation. There's also a section I added a week or
two ago about 'Managing Continuous Releases Using Subversion', that
contains a lot of tips about setting things up to depend on the right
versions between in-development packages.
Both of these new documentation sections were written to help clear up
questions or problems that were surfaced by Kevin or Ian in working
with each others' subversion stuff; hopefully the new docs (and new
features in some cases) will help get the subversion-based development
process more stable. (By the way, a quick thanks to everyone who
helped provide the feedback needed to guide the design of those docs
and features.)
[TurboGears] Re: errors on quickstart
Diwaker Gupta wrote:
pkg_resources.VersionConflict: (CherryPy 2.1.0-rc2
(/usr/lib/python2.4/site-packages/CherryPy-2.1.0_rc2-py2.4.egg),
Requirement.parse('CherryPy=2.1.0,!=2.1.0-beta,!=2.1.0-rc1,!=2.1.0-rc2'))
This message says that CherryPy 2.1.0-rc2 conflicts with the specified
requirement, which explicitly excludes 2.1.0-rc2 ('!=2.1.0-rc2').
Delete the conflicting egg
(/usr/lib/python2.4/site-packages/CherryPy-2.1.0_rc2-py2.4.egg) and
then run:
easy_install 'CherryPy=2.1.0,!=2.1.0-beta,!=2.1.0-rc1,!=2.1.0-rc2'
Notice that this is just pasting the requirement from the error message
above (in quotes so the shell won't think the is a redirect).
This problem is being caused by the 2.1.0-rc2 version number, which
setuptools thinks is a post-release patch rc2 of 2.1.0, not a
prerelease release candidate (which would be spelled 2.1.0rc2 or
2.1.0.rc2). As a result, it thinks the egg you have is newer than
the one that's needed, when in fact it's older.
Kevin, Ian: if I may make a suggestion... it might be easiest to fix
this issue in the field by releasing a CherryPy 2.1.1, and making
TurboGears and PasteScript depend on that, rather than trying to get
people to fix their individual installs like this. Meanwhile, I'll
continue doing penance for not having put prominent enough
documentation in the setuptools manual about how version number parsing
works. (It's buried in the pkg_resources docs under Parsing Utilties
at the moment.)
[TurboGears] Re: [Distutils] [TurboGears] hardcoded paths in tg-admin.exe and easy_install.exe?
At 10:17 PM 11/15/2005 -0600, Ian Bicking wrote: [EMAIL PROTECTED] wrote: Perhaps this has been mentioned already. So, forgive me if it has. I install Python into 'C:/Program Files/Python24' as I do not like to clutter up the C:/ portion of my file system. After installing turbogears and trying to begin the tutorial, I get the below error when I do this 'tg-admin quickstart': Program: can't open file 'Files\Python24\python.exe' : [Error 2] No such file or directory The same thing happens when I try to run easy_install.exe The .py versions of tg-admin and easy_install work fine... it's just the .exe versions that crash. I have named this the 'hard-coded python path bug'. Actually, it's not hardcoding that's the issue. It's that something somewhere is using spaces to parse the #! line. I'll look into this, as I'm not sure whether it's in the setuptools #! line code, or in the .exe's #! parser. Also, the instructions about adding 'C:\Python24' and 'C:\Python24\Scripts' to the PATH variable should be adjusted to wherever the user has actually installed Python ;) I make the assumption that somebody smart enough to be able to change the location should be smart enough to figure out how to adjust the instructions. :) No sense making the directions more complicated for everybody else.
[TurboGears] Re: [Distutils] [TurboGears] hardcoded paths in tg-admin.exe and easy_install.exe?
At 01:19 PM 11/16/2005 -0500, Phillip J. Eby wrote: At 10:17 PM 11/15/2005 -0600, Ian Bicking wrote: [EMAIL PROTECTED] wrote: Perhaps this has been mentioned already. So, forgive me if it has. I install Python into 'C:/Program Files/Python24' as I do not like to clutter up the C:/ portion of my file system. After installing turbogears and trying to begin the tutorial, I get the below error when I do this 'tg-admin quickstart': Program: can't open file 'Files\Python24\python.exe' : [Error 2] No such file or directory The same thing happens when I try to run easy_install.exe The .py versions of tg-admin and easy_install work fine... it's just the .exe versions that crash. I have named this the 'hard-coded python path bug'. Actually, it's not hardcoding that's the issue. It's that something somewhere is using spaces to parse the #! line. I'll look into this, as I'm not sure whether it's in the setuptools #! line code, or in the .exe's #! parser. Okay, it's more subtle than that. The problem is that something about how Python is spawned by the launcher, is causing Python to think that the space in its filename means that the part after the space is an argument. (I'd like to have an argument, please!) So I'm not quite sure how to fix it, exactly, particularly because I don't know if it's Python that's the problem, or the way the launcher is invoking Python. :(
[TurboGears] Setuptools 0.6a8 update to fix SourceForge problems
FYI, SourceForge changed their download pages such that older versions of setuptools can no longer recognize them and follow the links to the real download pages. I'm releasing 0.6a8 early in order to address these issues. You can update your setuptools with: easy_install -U setuptools If you have an 'ez_setup' subdirectory in a Subversion-based project, you can use 'svn update ez_setup' to ensure you're requiring the latest version. Unfortunately, there are still outstanding bugs, specifically the space in python.exe filename problem, and the issue with creating RPMs from source distributions that use the source-control-driven MANIFEST feature. However, these bugs are also in older versions, so they aren't new to 0.6a8. And 0.6a8 also fixes a lot of previous issues with doing Subversion-based development, so it's a good upgrade to get anyway. Sorry for the inconvenience; the original SourceForge processing code was a user contribution and I didn't really vet it for robustness in the face of SourceForge changes. The new parsing code could still be broken by future SF changes, but it's now less likely.
[TurboGears] Re: [Distutils] [TurboGears] hardcoded paths in tg-admin.exe and easy_install.exe?
Mark Mc Mahon wrote: On 11/16/05, Phillip J. Eby [EMAIL PROTECTED] wrote: SNIP Probably the issue here is that I need to be using some Windows API to invoke Python instead of execv/spawnv, in order to prevent the command line from being re-parsed. :( Failing that, using the short name API might be the best workaround, although technically I believe a short name can have a space in it too! It's just not as likely to. I think it cannot contain a space - DOS didn't allow spaces in names (dear old DOS :-) For example I created a file t t.txt with notepad and then did a dir /x 16/11/2005 16:40 PM 6 TTBC95~1.TXT t t.txt And you can see that the filename doesn't contain a space. I tried using again; it turns out I was testing the wrong version of the code, which explains why it so stubbornly refused to work. :) As it happens, both Python and the script name need to be quoted to avoid this issue. The only things I worry about now are: 1. If you have a quote mark in a directory name, you're probably screwed. :) 2. What happens to unquoted stuff later on the command line? But the quoting fixes are sufficient for now, so I'm going to just go with the double-quote solution rather than possibly introducing new issues with short names.
[TurboGears] Re: Setuptools 0.6a8 update to fix SourceForge problems
Rob Cakebread wrote: I've got CherryPy-2.1 final installed and it works fine with setuptools 0.6a7 With 0.6a8 I get this: $ tg-admin Traceback (most recent call last): File /usr/bin/tg-admin, line 5, in ? from pkg_resources import load_entry_point File /usr/lib64/python2.4/site-packages/setuptools-0.6a8-py2.4.egg/pkg_resources.py, line 2195, in ? for dist in working_set.resolve( File /usr/lib64/python2.4/site-packages/setuptools-0.6a8-py2.4.egg/pkg_resources.py, line 483, in resolve raise DistributionNotFound(req) # XXX put more info here pkg_resources.DistributionNotFound: CherryPy=2.1.0-rc2 I can import it fine with: python -c import cherrypy -rc2 is a patchlevel version, not a prerelease version. Thus, code that looks for =2.1.0-rc2 wants a version *later* than 2.1.0 final. Your requirement should list =2.1.0 instead. To avoid this problem in future, do not use '-' for prerelease tags; setuptools recognizes '2.1.0rc2' or '2.1.0.rc2' (or '2.1rc2') as equivalent prerelease versions, but '-' means post-release patch.
[TurboGears] Re: tg-admin quickstart issue w/svn version
[EMAIL PROTECTED] wrote: Running C:\Python24\python.exe setup.py egg_info Error (exit code: 1) Traceback (most recent call last): File setup.py, line 2, in ? from turbogears.finddata import find_package_data File d:\svn\turbogears\trunk\turbogears\__init__.py, line 11, in ? from turbogears import startup File d:\svn\turbogears\trunk\turbogears\startup.py, line 8, in ? pkg_resources.require(TurboGears) It looks like TurboGears is trying to require() code from inside your setup.py, which doesn't work right if your project hasn't got its PKG-INFO built yet. setuptools now has code to work around this problem, but it only takes effect when you call setup(). If you explicitly require() anything *before* calling setup(), it won't work correctly. TurboGears shouldn't be doing this with a newly-created project directory. Alternatively, it should create a PKG-INFO file for you (it only needs one line, e.g. Version: 0), or else it should *not* create the .egg-info subdirectory. Any of these things would fix the problem. The only thing I can think of that would fix this problem on the setuptools side (short of banning people from putting require() calls in library code, which I'm tempted to do anyway) is to pretend that .egg-info packages without PKG-INFO have a version number of 0. However, this won't necessarily produce the desired results either when you have a fresh checkout competing with installed eggs, and silently masks the issue which could then bite you in other ways. I think I'd rather have it visibly fail than silently do strange things. Maybe the right thing for me to do is to just have pkg_resources ignore .egg-info eggs that don't have a PKG-INFO file, after issuing a warning that it's doing so. It's not perfect, because it might let you use the wrong version for something, but at least it would warn you on every run until you ran setup.py develop or setup.py egg_info, and it would allow you to run those commands even if some library code in setup.py is calling require().
[TurboGears] Re: python 2.3
Paul Clifford wrote: * All decorators change from: @decorate def fn(...): ... to def fn(...): ... fn = decorate(fn) FYI, PyProtocols' protocols.advice module has support to make decorators that work in Python 2.3, with a few rather important limitations. First, the syntax is: [decorate()] def fn(...): The decorator has to be called, and it has to be specifically written to use the protocols.advice hooks. It may break a debugger that's running when the decorator is called. Decorating in multiple scopes at the same time may not work correctly. However, if you can live with all of those limitations, then you can get a decorator syntax that will work with both 2.3 and 2.4.
[TurboGears] Re: python 2.3
Jason Tackaberry wrote: Kevin Dangoor wrote: I'm curious as to why people are still running 2.3. The upgrade from 2.3 to 2.4 doesn't really break things, right? So why stick with 2.3? I'm presently evaluating TurboGears for an upcoming project and I must confess that, coming from the lead developer, this statement has given me pause. The two big commercial class distros (SuSE Enterprise and RHEL) are both packaged with python 2.3. Manually upgrading the system install of python to 2.4 on these distros is an invitation to disaster. Maintaining a parallel install of python 2.4 is certainly possible, but it makes me very wary. That's something I do on development boxes, not production servers. Do you never build an RPM for something your distro doesn't offer? That seems like an odd stance to take. Note that Python itself uses a well-defined naming and versioning scheme for its installation to allow different versions to happily co-exist. If you use make altinstall to build your Python 2.4 package, it will give you a python2.4 binary but not a python binary, leaving your system Python entirely unaffected. Similarly, libraries go to prefix/lib/python2.4 instead of python2.3, etc. On at least one machine I administer, I have a system Python that's Python 2.2, and an altinstalled 2.3 and 2.4. Then, vendor-provided stuff uses 2.2, and my things run with 2.3 or 2.4, depending on their needs. In my last enterprise shop, we couldn't rely on getting anything particularly current on our app servers from RHEL, so our apps were built using the NetBSD pkgsrc system to build our own Python versions and their dependencies, as well as the applications themselves. We then simply managed those separate packages, rendering unto the SA's what was RHEL's, and unto our apps what was our application platform. :) So, in short, I'd encourage you to simply consider Python 2.4 part of your application platform, and the system Python as merely part of the operating system. There's no need to mix the two, and many reasons *not* to mix them even if they did happen to be the same version. Whether you use the same packaging system for your application platform and your OS is also a decision that's up to you as an application designer. The boxes are there to serve you, so you can serve the users; your app doesn't exist to serve the boxes' system administrators or Red Hat, unless of course you're writing system administrator applications for Red Hat. :)
[TurboGears] Re: Trouble installing on Debian unstable
Martin Skøtt wrote: Could it be there is something missing in /usr/local/lib/python2.4/site-packages ? Currently it just contains a bunch of .egg files and .edd directories. As Kevin already pointed out, you're missing the .pth files. You need to include that directory in the --site-dirs option to easy_install. See: http://peak.telecommunity.com/DevCenter/EasyInstall#command-line-options under the --site-dirs option for an explanation of how to set up an alternate installation location. If you follow those directions and then install again, you should end up with two more files: setuptools.pth and easy_install.pth, and Python should actually recognize the directory then. Basically those are the instructions for installing in a non-standard location when you are root and can therefore do those setup steps in your main Python installation. Just substitute /usr/local/lib/python2.4/site-packages for the ~/lib/python2.3 example directory in the instructions and you should be good to go. Also, if you want the /usr/local directory to be the default installation location so you don't have to use -d all the time, you can also add: [install] install_lib = /usr/local/lib/python2.4/site-packages to the distutils.cfg file as described in the instructions, in addition to the site_dirs setting.
[TurboGears] Re: Trouble installing on Debian unstable
Martin Skøtt wrote: On Thu, Nov 10, 2005 at 08:09:47AM -0800, Phillip J. Eby wrote: One strange thing is that my ~/.pydistutils.cfg has been looking like this all the time: [install] install_lib = /usr/local/lib/python$py_version_short/site-packages [easy_install] site_dirs=/usr/local/lib/python$py_version_short/site-packages I guess --site-dirs is the same as site_dirs being set in the file? Yes. You can set the default for any easy_install option that way. For boolean options, set them to 1. Note, however, that the [easy_install] section does *not* support $ variables, so the above configuration probably doesn't work correctly. The $ variables only work in the [install] section, and no, you can't put site_dirs there. Just list the paths explicitly in site_dirs. to the distutils.cfg file as described in the instructions, in addition to the site_dirs setting. I just noticed that neither python2.3 or python2.4 in Debian include a distutils.cfg file. It sounds like a bug to me, so I will try to contact the package maintainer and get him to add it (since the /usr/local/lib/python*/site-packages dir is created by the package). That would be good, as long as they also include the altinstall.pth so that the .pth files in the /usr/local tree get handled. By having a distutils/distutils.cfg with the defaults set as well, they will make it easy for people to actually use /usr/local, and people won't have as many problems using EasyInstall. They *do*, however, need to have the /usr/local/ site-packages directory in sys.path come *before* the /usr one, though, or locally installed packages won't be able to override the system-installed ones. I will add some info about this to http://trac.turbogears.org/turbogears/wiki/SystemInstall so other Debian user won't run into the same trouble. Good idea, and thanks.
[TurboGears] Re: Trouble installing on Debian unstable
Martin Skøtt wrote: Great, I hope it's okay with you that I quote the above in my message to the maintainer. I'll go further than that - feel free to have them contact me directly if they'd like me to review their plans or patches. I want to help system packagers make their systems as egg friendly as possible.
[TurboGears] Re: Installation with no internet connection
Chackero wrote: Lately, I am without InterNet in house. I have all the packages that the necessary TurboGears, with exception of the Setuptools. How I get setuptools without using ez_setup.py? Put the setuptools egg in the same directory as ez_setup.py, and when you run ez_setup.py it will find the egg and not download it. Links to the eggs may be found at: http://cheeseshop.python.org/pypi/setuptools
[TurboGears] Re: Installation with no internet connection
Elvelind Grandin wrote: You would need to download all the eggs More precisely, you need to download only the eggs for your platform. If you're on Windows, you don't need the Mac eggs or vice versa. If a particular package doesn't have either a generic egg, or an egg for your platform, you'll need to download the source package. Download them all into a directory, and then use that directory on the easy_install command line in place of the TurboGears download URL, e.g.: ez_setup.py -f somedir --script-dir=/usr/local/bin TurboGears where somedir is the directory where the eggs and source package(s) are. EasyInstall will then attempt to satisfy all the dependencies using the contents of somedir. On 11/7/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I have to do a TurboGears installation with no Internet connection. What I want to know is if I have to download all the packages listed here http://www.turbogears.com/download/index.html or only the TurboGears egg should do.
[TurboGears] Re: Installation with no internet connection
[EMAIL PROTECTED] wrote: Sound just like what I need. I doing the installation on Windows, tough and I'm not sure what the --script-dir flag stands for. --script-dir sets the location where commands like tg-admin and easy_install will be installed. On Windows, you should pick a directory on your PATH, or omit the option altogether, in which case the scripts will go in C:\Python24\Scripts. If you install them there, you'll have to include that path when you run them, so you may want to either put that directory on your PATH, or else use a --script-dir that's already on your PATH.
[TurboGears] Re: I broke my TG install :D
Kevin Dangoor wrote: On 11/4/05, Phillip J. Eby [EMAIL PROTECTED] wrote: asimov:~/turbogears jeremy$ sudo python setup.py develop --script-dir=/usr/local/bin Traceback (most recent call last): File setup.py, line 14, in ? from docgen import GenSite File /Users/jeremy/turbogears/docgen.py, line 7, in ? pkg_resources.require(Kid = 0.6.4) Your setup script imports docgen, which in turn runs the require(). Modules really shouldn't require() in this way. I'm puzzled as to why explicitly asking for Kid = 0.6.4 cares about the TurboGears egg info... Because to determine whether Kid is available, pkg_resources has to scan sys.path, and in the process it encounters the (broken) Turbogears egg. That's why the source not being on sys.path would fix it. Is your suggestion that the module should just import kid? Or at least wait until it's actually needed, rather than doing the require() at module level. I assume docgen is only needed for certain commands, not to run develop or egg_info. I hadn't put the source under an src directory because I knew there would only be one directory there. It seemed kind of overkill... we certainly *could* move the source down a level... Only if you want to fix this before I get around to the version hack I described, assuming I can get that to work. I do plan to try to get it working this weekend, at least for the in-development version of setuptools. Then, nobody will have to worry about this issue again; things will Just Work.
[TurboGears] Re: I broke my TG install :D
Kevin Dangoor wrote: ugh. At one point, I had checked in the .egg-info directory, but then people complained about getting conflicts there. try python setup.py egg_info and then rerun the develop command. That's not gonna work. See below. asimov:~/turbogears jeremy$ sudo python setup.py develop --script-dir=/usr/local/bin Traceback (most recent call last): File setup.py, line 14, in ? from docgen import GenSite File /Users/jeremy/turbogears/docgen.py, line 7, in ? pkg_resources.require(Kid = 0.6.4) Your setup script imports docgen, which in turn runs the require(). Modules really shouldn't require() in this way. But you're not entirely at fault; the key problems here are that: 1. A project that hasn't run egg_info is essentially broken 2. A project that has its source code in the project root (as opposed to a lib or src subdirectory) is always on sys.path If you change either of these things, the problem goes away. Using a subdirectory makes it go away altogether.I hadn't actually thought about this before, it's just that my projects usually have a 'src' directory, so I haven't run into this issue. Plus it only happens when you start a project, unless you're a user working from a checkout. Users working from an sdist never see an issue. The only other thing I can think of to do is to force the setup script to *remove* the project egg from the working set, or perhaps forcibly set its version number! This won't take it off sys.path, of course, nor would it necessarily be the *right* version number (due to egg_info not having been run yet), but it would fix the brokenness and end the include .egg-info or not include .egg-info debate. :) I'd also have to change egg_info to ajust the version number of the in-memory distribution object, but that's not a big deal. Looks like the final 0.6a8 release is going to be the Subversion development release - so far most of the features and bugfixes in 0.6a8 are to support users who are tracking the Subversion release of a project, or sdist snapshots thereof.
[TurboGears] Re: conflict installing elementtree (FC4)
[EMAIL PROTECTED] wrote: No. setuptools(egg) is incompatible with all major distro package system I know of. Hopefully, that won't be true for very long. There are projects out there such as easy_deb, along with people working on RPM support for eggs, and egg support for gentoo. None of these are official yet, but in the long run hopefully most systems will have some support for them. It is clean, doesn't interfere with your production environment. The -D option or whatever conflict resolving option by setuptools are in general not acceptable for a well maintained system. Yes, the -D option is intended to remove Python packages that were manually installed, so if manual installation is not well-maintained, then your statement is true by definition. :) However, the truth is that many people have systems where manual installation via setup.py install is de rigeur, especially development systems.
[TurboGears] Re: I broke my TG install :D
Jeremy wrote: Now, whenever I run tg-admin, I get: asimov:~/turbogears jeremy$ tg-admin /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a7-py2.4.egg/pkg_resources.py:1943: UserWarning: Module paste was already imported from /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/PasteDeploy-0.3-py2.4.egg/paste/__init__.pyc, but /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/Paste-0.3-py2.4.egg is being added to sys.path This warning is because Paste 0.3 does not declare 'paste' to be a namespace package, even though PasteDeploy 0.3 does. The conflict checking currently only verifies that there are no conflicts with namespace packages listed in the egg being added to sys.path. I've changed this so it also ignores already-declared namespace packages, and also so that the error message shows a line in user code rather than in pkg_resources. The latest SVN revision of setuptools (0.6a8dev-41391) now has these fixes; you can upgrade to it with 'easy_install setuptools==dev'. Of course, you should include the --script-dir=/usr/local/bin option if your setup requires it. Note that you can edit ~/.pydistutils.cfg and add these lines: [install] install_scripts = /usr/local/bin if you want easy_install to always use /usr/local/bin for scripts, and then you won't need to use --script-dir all the time. (Just to be clear, the warning above is in this specific case harmless, so you don't need to upgrade setuptools or do any other steps I've listed here unless you just want to get rid of the warning. However, you should not assume that every similar conflict warning is harmless! It's only this specific message which I've investigated and reproduced, that is a false alarm.)
[TurboGears] Re: I broke my TG install :D
Kevin Dangoor wrote: On 11/3/05, Phillip J. Eby [EMAIL PROTECTED] wrote: (Just to be clear, the warning above is in this specific case harmless, so you don't need to upgrade setuptools or do any other steps I've listed here unless you just want to get rid of the warning. However, you should not assume that every similar conflict warning is harmless! It's only this specific message which I've investigated and reproduced, that is a false alarm.) Also of note is that Ian Bicking has corrected this for the next release of Paste. And while we're speaking of next-gen features, I've just made the 'develop' command in subversion take all the same options as easy_install, and inherit the easy_install settings from any configuration files. So if you set e.g.: [easy_install] find_links = http://turbogears.org/download/ in setup.cfg, then setup.py develop will use this option. Or you can use -f with develop, etc. Anyway, I seem to recall you wanting something like that. Enjoy.
[TurboGears] Re: error upgrading from TG0.8a1 to 0.83a : elementtree ?
[EMAIL PROTECTED] wrote: I noticed this problem when I tried this: $ python ez_setup.py -UDf http://turbogears.org/download/ TurboGears If you have setuptools 0.6a7, you can add '--allow-hosts=turbogears.org' before the '-UDf' in order to make setuptools only download files from turbogears.org; this will work around the problem with effbot.org's link format for the time being.
[TurboGears] Re: PyProtocols and jsonify.
Kevin Dangoor wrote: On 11/1/05, Phillip J. Eby [EMAIL PROTECTED] wrote: Kevin Dangoor wrote: I fixed the Mac eggs... but, won't anyone on Linux run into this problem? If they easy_install and it picks up the source zip, will the version number come from the zip name or will it come from the setup file? From the setup file. It'd probably be a best practice for code that's in development in Subversion to have a setup.cfg that sets the right egg_info flags. Then, I suppose when you branch for a release you can take those options out of the release branch. That way, if you develop on the trunk, then a trunk checkout will always be properly tagged with the version. But this still means that source distributions like the ones at http://peak.telecommunity.com/snapshots will have the version skew issue if someone actually installs it. Not exactly. '0.5a0dev' is a *lower* version number than '0.5a0dev-r123', so this doesn't result in any breakage. It does make me think, however, that 'sdist' should maybe somehow stick the subversion revision into the source distribution, but only if your setup.cfg specifies that you're doing subversion tags. Interestingly, the source distribution's PKG-INFO will already contain this information... Hm. Maybe what I could do is have the egg_info command check for a PKG-INFO in the setup directory, and then read the version info from there if there's no .svn directory to read it from. That way, source distributions would automatically keep the subversion revision tag they were built with. I'll definitely look into this, as it would completely close this particular loophole.
[TurboGears] Re: rule dispatch
[EMAIL PROTECTED] wrote: may be -f is better as it search for a larger pool but since I only need those needed by TurboGears, -i is enough for me, so long it is properly maintained on TurboGear's index :-) -f tells easy_install to read the specified page for any links on it, while -i tells TurboGears to do all PyPI lookups using the specified page as a base URL. The difference is that -i is going to make easy_install try to look up URLs like 'http://www.turbogears.org/download/index.html/RuleDispatch/', which of course won't work. It will then fall back to the plain URL, so it's basically just a really wasteful way of doing the same thing as -f in this case. :) The idea of -i is for if you run your own version of PyPI, or if the PyPI URL changes between releases of setuptools and you need to override its default. The -f option, on the other hand, is for reading user-provided link pages, such as the TurboGears download page.
[TurboGears] Re: SVN Checkout Problem
At 11:26 AM 10/31/2005 -0800, Bob Ippolito wrote: On Oct 31, 2005, at 11:11 AM, SuperJared wrote: When attempting to check out TG: Fetching external item into 'turbogears/thirdparty/sqlobject/ ez_setup' svn: Unknown hostname 'svn.eby-sarna.com' Is anyone able to resolve that host? Looks like his DNS is down, but it appears that 64.239.5.21 is the correct IP address. If you toss that in your hosts file or equivalent you might be able to do it. I think I've got the DNS problem fixed, at least temporarily. Unfortunately two of the three DNS servers for the eby-sarna.com domain don't have any power backup and are down due to hurricane Wilma. The third was refusing to serve the slaved, out-of-date zone file, so I've changed it to be the master for now.
[TurboGears] Re: SVN Checkout Problem
Ian Bicking wrote: Now that Python has moved to svn, maybe there's an svn external that can be set up pointing to that server? Not yet; the name of the file in SVN is 'ez_setup.py', but you can only do an external to directories, not individual files. The other issue of course is that the eby-sarna SVN version is only updated when I actually make a release, which is not necessarily the same time at which I update the version numbers in revision control! So, I don't think I'll be changing this at the moment, without some thought as to how to keep it separate.
[TurboGears] Re: Deploying a TG app
Aggelos Orfanakos wrote: It worked like a charm. Thanks for your help. Note also that as long as the setup.py lists TurboGears as a requirement, it should be possible for somebody to install your application with just the .egg and easy_install - including the installation of TurboGears itself, with all its dependencies. This is a pretty killer feature for application deployment, especially since it will also upgrade TurboGears if you use an app that needs a later version of something, etc. If your application has other dependencies besides TurboGears, those can get installed too.
[TurboGears] Re: setuptools and file exists problem
At 07:07 PM 10/23/2005 -0500, Ian Bicking wrote: Kevin Dangoor wrote: I thought that was why Ian made paster? Yes, there would be overlap, and it would be good to consider how best to deal with that. If the paster create code goes into nest, I have no problem with deprecating its presence in paster; if fact, if most of Paste Script goes into nest that'd be fine too. Maybe it could just be a renaming operation at that point. I was thinking that might be the case. Indeed, I've kind of thought that paster might more or less just become nest and be done with it. ;) There's some web-specific stuff in Paste Script -- particular some wrappers for Paste Deploy around some third-party packages and paster serve, but those could just be moved to Paste Deploy. But the basic frontend and general pluggability seems to apply well to nest. I'm A-OK with reducing the number of frontends. My thought is that templates for nest will get registered via entry points, so there should be lots of room for variation in how they get implemented. I was thinking that nest would provide some kind of base class for templates, and you'd just have subclasses or instances or something for frameworks with special needs. But at this point I haven't even looked at what paster create and tg-admin quickstart currently do. Actually implementing Nest still isn't on my radar screen yet, and I don't personally have enough use cases to shape the templating system yet. So it'll be good to look at what features have actually been found useful in the field, even if the examples are all in the web apps arena at the moment.
[TurboGears] Re: setuptools and file exists problem
Kevin Dangoor wrote: On 10/21/05, Phillip J. Eby [EMAIL PROTECTED] wrote: Kevin Dangoor wrote: I just remembered that Windows file modification time apparently is only accurate within a couple of seconds. rsync has a parameter to deal with this skew. So, if you're checking modification times to see if you should overwrite a file, you may want to apply a small bit of slush instead of a straight ==. Wouldn't that fail consistently, then? I mean, each time the file gets extracted, the time would be wrong again in that case. I had thought that the problem was something to do with how the modification time was stored, but (from a quick google search) it actually appears to be related to how the modification time is created in the first place. Given that, I think you're right... it would be consistent. I think I've got this figured out, now, or at least I've figured out one way to cause this. If you install an egg of a given version, let's say TurboGears 0.8a1, and you then *rebuild the egg without changing the version number* and reinstall it (or the distributor rebuilds it and you reinstall it), *and* you're on Windows, *and* you used it at least once before reinstalling, *and* it contains a C extension and was installed zipped... then you will get this error. I went back to look at previous reports of this error to see if they matched all these criteria, and it's hard to tell whether the rebuild+reinstall occurred in each case. Sometimes people said they quote installed from scratch, but it's not clear whether they really meant installing or reinstallling, and impossible to tell if an egg rebuild was involved. But, this is definitely a way to create the problem, so I'm going to fix it for the official release of 0.6a6 this weekend. The problem is that in this scenario, there's an existing copy of the C extension extracted, but Windows doesn't delete a destination file when you rename a source file to it. The code checks in this case to see if the target file has the same size and timestamp as what it's trying to extract, and if so assumes it's done. If they're different (as they could be after a rebuild), it currently punts, on the theory that something's wrong. On Windows, however, it should try to remove the old file and then attempt to replace it again.
[TurboGears] Re: Debian Sarge Install
gh wrote:
Correction/Addition.
The previous works fine for installation but kid won't run.
I created ~/py/sitecustomize.py
cat py/sitecustomize.py EOF
import sys, os, os.path
setuptools_dir = '/usr/local/lib/python2.4/site-packages'
for x in os.listdir(os.path.expanduser(setuptools_dir)):
eggpath = os.path.join(setuptools_dir, x)
if x.endswith('.egg') and os.path.isdir(eggpath):
sys.path.insert(0, eggpath)
EOF
I strongly recommend that people *not* do this! You will prevent
easy_install from being able to work correctly with your installation
in the future!
Setuptools 0.6a6 supports installation to almost any directory using
PYTHONPATH if you want to do it that way, and it also includes a script
to setup a virtual Python if you prefer using that approach. But you
will need to get rid of the above cruft.
For the correct non-root installation instructions for 0.6a6, please
see:
http://cvs.sourceforge.net/viewcvs.py/python/python/nondist/sandbox/setuptools/EasyInstall.txt?view=markup
Or better yet, just use this script to create a ~/bin/python that will
do everything as it should:
http://peak.telecommunity.com/dist/virtual-python.py
It should work even with setuptools 0.6a5.
I strongly recommend that you get rid of the sitecustomize.py and the
/usr/local stuff you did, and use either the virtual-python script or
upgrade to setuptools 0.6a6 from CVS.
Please, don't anybody else do what's described here - easy_install will
NOT work properly if you do this. Somebody posted these broken
instructions to the Wiki, but I got distracted working on 0.6a6 and
forgot to delete them from the Wiki. I've now added a warning to the
wiki page that you should BACK OUT these steps if you've done them.
Use the virtual-python script or use 0.6a6; those are the only safe
choices.
[TurboGears] Re: setuptools and file exists problem
[EMAIL PROTECTED] wrote: This is not related to the problem mentioned, but is there a simple way to upgrade and remove older version ? I do a : easy_install -U setuptools and now I have two version of it, 0.6a5 and 0.6a6. I know this facilitate multiple version but just wonder if there is a way to say : clean up site-packages as I am now satisfied with the latest version of packages inside them. Not at the moment; just 'rm -rf' anything you're not using. In the 0.7 or 0.8 timeframe, there will be a 'nest' tool for managing eggs, which will support listing and deleting eggs, along with other to-be-determined package management operations. (Such as project creation ala 'paster create' and 'tg-admin quickstart' - I'd like to have a general purpose project template system so more people don't have to keep rolling their own such systems.)
[TurboGears] Re: Installation Doc update request
Kevin Dangoor wrote: On 10/22/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I had the same problem on a knoppix HD install. Would it be very difficult to add a check and instructions to fix the problem? If we're trying to make this as painless as possible to get started, I think it would be useful. We could lobby for Phillip Eby to add a note to that error message saying something like To correct this, you may need to install a python-dev package. That error message is from the distutils.sysconfig module, not from setuptools, so I'm not in a position to do much about it. Incomplete Python installations make the distutils cry. :) If you encounter this problem as a user, please ask your packaging system provider why they feel it is necessary to cut the snake in half and only ship you the tail. Perhaps through vendor education we can stop this needless, shameless abuse of innocent reptiles. :) And yes, it's quite difficult to detect the issue in the general case - there is no standard way in which vendors carve up Python, since carving it up is by definition non-standard! Some omit the distutils, some just exclude the .h files, etc. It would be far saner to just push the pain back to the packagers. Please politely ask your distributor to stop cutting your snake into little pieces; in the long run it makes more sense than trying to write tests for every possible new way in which they can break Python. Indeed, some of them seem to come up with new ways all the time, such as the Mandriva pyconfig.h insanity that came up earlier this week.
[TurboGears] Re: Problem encountered while installing TurboGears
Anthoni Shogan wrote:
Hi everyone,
I use Debian, and I'm trying to install TurboGears-0.8a3. Just got
Python 2.4.2 running.
Now, is TurboGears-0.8a3 compatible with Python-2.4.2??
I did not have easy install, so I had to go in for the two step
installation.
After running,
|python ez_setup.py -f http://www.turbogears.org/download/index.html
--script-dir /usr/local/bin TurboGears
as root I got the following message:
No local packages or download links found for kid=0.7adev-r186
error: Could not find distribution for
Requirement.parse('kid=0.7adev-r186')
As suggested in the additional installation information, I downloaded
the eggs (yeah, I'm behind a fire wall)
to /tmp and tried the following command:
|easy_install -f /temp TurboGears
result was a, bash: easy_install: command not found.
I notice you didn't include 'sudo' on your run of ez_setup.py. Since
it has to be able to write to /usr/local/bin and also to Python's
site-packages, you need to run it as root, or else follow the non-root
installation procedure that sets up a virtual python in your home
directory that you can install packages to without being root.
[TurboGears] Re: error upgrading from TG0.8a1 to 0.83a : elementtree ?
[EMAIL PROTECTED] wrote: I encountered problems upgrading today. Any ideas? -Todd You left off the '-f http://turbogears.org/download/', so that EasyInstall will use the Turbogears-supplied download links. I believe this would actually have worked correctly the way you typed it, if Kevin had put a link to http://turbogears.org/download/ in his download URL on the TurboGears PyPI page at http://python.org/pypi/TurboGears/ .
[TurboGears] Re: Did this update right?
modmans2ndcoming wrote: is that all it says with the latest update? I'd have expected to see some lines about writing the tg-admin script. Did you upgrade setuptools first?
[TurboGears] Re: ARG, the system is nuked!!!
modmans2ndcoming wrote: it appears that I do not have the helper scripts like easy_install. how do I get that? Try ez_setup.py setuptools TurboGears; I believe that should reinstall the scripts for both, if you still have the eggs present. If not, it's going to try to download them, which will work for setuptools but not for TurboGears.
[TurboGears] Re: Did this update right?
modmans2ndcoming wrote: no, I just did the easy install ez_setup.py -U setuptools will install the latest setuptools version; try that before you upgrade your TurboGears.
[TurboGears] Re: Windows Install Errors
DCA wrote:
C:\Python24ez_setup.py -f
http://www.turbogears.org/download/index.html TurboGe
ars
Reading http://www.turbogears.org/download/index.html
Searching for TurboGears
Reading http://www.python.org/pypi/TurboGears/
No local packages or download links found for TurboGears
error: Could not find distribution for Requirement.parse('TurboGears')
Are you behind a firewall, perhaps? The overall pattern of errors in
this thread seems consistent with a firewall returning a login page or
other HTML page in place of what EasyInstall is trying to download,
thereby preventing EasyInstall from finding the download links or
downloading valid .egg files.
If that's the case, you'll need to either find a way to bypass the
firewall (e.g. using http://ntlmaps.sf.net/ ), or else manually
download all the .egg files listed on the download page to a temporary
directory, and then run
easy_install -f dldir TurboGears
where 'dldir' is the directory you downloaded the .egg files to.
