FastData is now part of TurboGears[exp]

[Kevin Dangoor]

As we approach stability of the TurboGears 0.9 codebase, it's good to
take a look at what we've got and decide what's really good and useful
right now. 0.9 includes a bunch of major new components: identity,
i18n, widgets, the Toolbox, CatWalk, Model Designer, FastData.

FastData, simply put, is not ready for prime time. There's good
potential, but it needs a much more complete implementation and more
customizability before it's truly useful. Starting with today's 0.9a3
release (coming soon), FastData is no longer included with TurboGears.

In the process of breaking FastData out into a new TGFastData package,
it's become clear that this is a good model going forward. It's a way
to incubate new ideas and potentially move things forward more
quickly. There may even prove to be advantages in breaking out other
pieces of TurboGears (but they'd remain a part of the "core", in that
easy_install TurboGears will get you all of the parts).

If you use and like FastData, there's no reason to stop.

easy_install -f http://www.turbogears.org/preview/download/ TurboGears[exp]

will install TurboGears and all "experimental" parts, which is just
FastData right now. You can also install FastData explicitly:

easy_install -f http://www.turbogears.org/preview/download/ TGFastData

(Neither of those easy_install commands will work until after you have 0.9a3)

SVN for FastData is here:
http://www.turbogears.org/svn/turbogears/projects/FastData/trunk/

Kevin

--
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

[Jason Chu]

What will people using svn have to do to keep using fast data? I
assume that it'll be pulled in to the thirdparty folder, but are there
any commands we'll need other than python setup.py develop?

Jason

[Kevin Dangoor]

On 4/4/06, Jason Chu <jc...@xentac.net> wrote:
> What will people using svn have to do to keep using fast data? I
> assume that it'll be pulled in to the thirdparty folder, but are there
> any commands we'll need other than python setup.py develop?

I haven't put an external in for it yet, but I'll do that.

Beyond setup.py develop, you won't need to do anything.

Kevin

[Tim Lesher]

Yes, I'm jumping the gun here :-)

On Windows XP, this:

easy_install -f http://www.turbogears.org/preview/download/ TurboGears[exp]

fails:

Searching for setuptools>=0.6a11
Reading http://www.python.org/pypi/setuptools/
Reading http://peak.telecommunity.com/DevCenter/setuptools
Reading http://www.python.org/pypi/setuptools/0.6a11
Best match: setuptools 0.6a11
Downloading http://www.turbogears.org/preview/download/eggs/setuptools-0.6a11-py
2.4.egg
Processing setuptools-0.6a11-py2.4.egg
creating c:\python24\lib\site-packages\setuptools-0.6a11-py2.4.egg
Extracting setuptools-0.6a11-py2.4.egg to c:\python24\lib\site-packages
Removing setuptools 0.6a10 from easy-install.pth file
Adding setuptools 0.6a11 to easy-install.pth file
Installing easy_install-script.py script to c:\python24\Scripts
Installing easy_install.exe script to c:\python24\Scripts
error: c:\python24\Scripts\easy_install.exe: Permission denied

Because on Windows, an executable is unwritable while it's running.

This, however, should work:

python c:\python24\scripts\easy_install-script.py -Uf http://
www.turbogears.org/preview/download/index.html TurboGears[exp]

--
Tim Lesher <tle...@gmail.com>

[Kevin Dangoor]

On 4/4/06, Tim Lesher <tle...@gmail.com> wrote:
> error: c:\python24\Scripts\easy_install.exe: Permission denied
>
> Because on Windows, an executable is unwritable while it's running.

Which is why the upgrade instructions recommend upgrading setuptools first:

http://www.turbogears.org/preview/download/upgrade.html

Kevin

[Tim Lesher]

I understand--the part I was missing was that you always have to
download a new ez_setup.py, since using a previous one won't upgrade
to a newer version of setuptools, even with the -U flag.

--
Tim Lesher <tle...@gmail.com>

[Kevin Dangoor]

On 4/4/06, Tim Lesher <tle...@gmail.com> wrote:
> I understand--the part I was missing was that you always have to
> download a new ez_setup.py, since using a previous one won't upgrade
> to a newer version of setuptools, even with the -U flag.

Ahh, yes. I can see that. It *would* be cool if easy_install could
upgrade itself in place. Alas...

Kevin

[Tim Lesher]

I can see how it could be cause problems, but so far, substituting
"python [pythondir]\scripts\easy_install_script.py" for "easy_install"
in the TG upgrade instructions for Windows has seemed to work each
time for me. If you use the script, easy_install updates setuptools
fine (assuming they haven't changed the API between the two revisions,
of course).
--
Tim Lesher <tle...@gmail.com>

[qvx]

This easy_install stuff botheres me a lot.

I'm using 0.9a2. I tested against 0.9a2. I have all 0.9a2 eggs inside
my setup directory.

Today, when I was trying to deploy my 0.9a2 application to production
server, I was unplesantly surprised that it tried to install all
*latest* stuf from internet even though I said:

D:\Incomming\Python\TurboGears>easy_install -U -f
D:\Incomming\Python\TurboGears TurboGears

I simply ignores -f and goes to web to see what latest is there to be
found. If I'm lucky enough and there is same (latest) version on the
web as in my local directory it will use local copy which only saves me
the trouble of download. Unfortunately, it doesn't isolate me from all
new changes that I *don't* wont untill I test my app with it.

In the end I had to copy my Python24 directory from dev box to
production box and fix all easy-install.pth entries. Now I have around
20 unnecessary packages on my production box that I don't need. I was
lucky it was the same OS.

Tvrtko

[ajones]

I'm no expert on easy_install, but I think you should have been able to
do that with:
easy_install -f D:\Incomming\Python\TurboGears TurboGears

There may be a "upgrade from this location only" option, but evidently
-U is not it.

[ajones]

I know this is kind of silly, but instead of labelling this
TurboGears[exp] how about calling it something like TurboGearsWorkshop?
My reasoning is that TurboGears[exp], to me at least, implies a
development or testing build of the full suite instead of select
components. I just think it could get confusing for people trying to
initially figure out the project.

[Jorge Godoy]

"ajones" <ajo...@gmail.com> writes:

I'm also worried with the use of "[" and "]" in the name. It might be special
somewhere (in shell it is, for example) and this might cause hidden troubles.

I believe that the "exp" was intentional and means "experimental". This
feature is yet in development and might later migrate back to TG or to some
specific package without the "exp" suffix. At least this is how I read it
from the name...

--
Jorge Godoy <jgo...@gmail.com>

[Robin Haswell]

TurboGearsCogs?

We've already had cogs been suggested as the name for TG addons (CogBin)

-Rob

[Michele Cella]

+1 for using something other than [exp].

Ciao
Michele

[Jorge Vargas]

+2 :)

[Damjan]

>> I understand--the part I was missing was that you always have to
>> download a new ez_setup.py, since using a previous one won't upgrade
>> to a newer version of setuptools, even with the -U flag.

> Ahh, yes. I can see that. It *would* be cool if easy_install could
> upgrade itself in place. Alas...

How do you mean "in place", "easy_install -U setuptools" has worked for
me always (I'm on Linux though).

[Robin Haswell]

I think this discussion is related to Windows

-Rob

[Phillip J. Eby]

qvx wrote:
>
> Today, when I was trying to deploy my 0.9a2 application to production
> server, I was unplesantly surprised that it tried to install all
> *latest* stuf from internet even though I said:
>
> D:\Incomming\Python\TurboGears>easy_install -U -f
> D:\Incomming\Python\TurboGears TurboGears
>
> I simply ignores -f and goes to web to see what latest is there to be
> found.

-U tells easy_install to search the net *even if* a local version is
available.

Meanwhile, -f gives a list of *additional* URLs to search; it does not
restrict easy_install from going to the net - especially if you use -U.

Thus, if you want easy_install to do a minimal search (no net access
unless a package isn't found locally at all), do *not* use -U, as the
whole point of -U is to *force* easy_install to search the net.

Finally, if you want to restrict easy_install from downloading *even
if* a package isn't available locally, use the --allow-hosts option to
restrict it to the desired hosts:

http://peak.telecommunity.com/DevCenter/EasyInstall#restricting-downloads-with-allow-hosts

http://peak.telecommunity.com/DevCenter/EasyInstall#installing-on-un-networked-machines

[ajones]

It is related to windows. NTFS, or whatever subsystem is handling this,
has no concept similar to an inode. Most upgrades to an existing file
can only be made while that file is not actively in use. I'm sure there
is a way around this, but it probably takes some deep vodoo to
accomplish, and is much more difficult than telling people to use
ez_setup.py to upgrade setuptools.

[Tim Lesher]

That's correct. Under Linux you can replace an executable while it's
running; under Windows, you can't.
--
Tim Lesher <tle...@gmail.com>

[Qvx]

I will try this next time.

My understanding of -U was to force upgrade my already installed packages. I had many TG packages from several months ago on production box and I was trying to upgrade to a set of packages that can be found inside my local directory.

Now I see I was wrong. Thanks for sorting this out.

[Tim Lesher]

All it requires is using this:

python easy_install_script.py [yadda]

instead of this:

easy_install [yadda]

On Windows, "easy_install" translates to "easy_install.exe", which is
a hack to get around the fact that the Window command shell doesn't
peek at the first line for #! commands.

--
Tim Lesher <tle...@gmail.com>

[Kevin Dangoor]

On 4/5/06, Jorge Godoy <jgo...@gmail.com> wrote:
>
> "ajones" <ajo...@gmail.com> writes:
>
> > I know this is kind of silly, but instead of labelling this
> > TurboGears[exp] how about calling it something like TurboGearsWorkshop?
> > My reasoning is that TurboGears[exp], to me at least, implies a
> > development or testing build of the full suite instead of select
> > components. I just think it could get confusing for people trying to
> > initially figure out the project.

People initially trying to figure out the project shouldn't use
FastData at this point. It gets you going quickly, but doesn't handle
enough cases or provide enough customization to be much more than
frustrating.

> I'm also worried with the use of "[" and "]" in the name. It might be special
> somewhere (in shell it is, for example) and this might cause hidden troubles.

This is the syntax used by Easy Install for "extras". If it's special
in shell, you can just put quotes around it.

> I believe that the "exp" was intentional and means "experimental". This
> feature is yet in development and might later migrate back to TG or to some
> specific package without the "exp" suffix. At least this is how I read it
> from the name...

That's exactly correct. When FastData's ready, easy_install TurboGears
will get you FastData as well. Until then, you have to conciously
choose to install the experimental stuff.

Kevin

[Kevin Dangoor]

On 4/5/06, Robin Haswell <r...@digital-crocus.com> wrote:
>
> TurboGearsCogs?
>
> We've already had cogs been suggested as the name for TG addons (CogBin)

Except those things are (potentially) useful and usable now. This
particular case is a case of something that's planned or desired for
the TG core, but is just not ready yet.

Kevin

[Robin Haswell]

You know I use FastData at the moment for managing a two-field object.
It seems to work fine for me :-)

-Rob

[Jorge Vargas]

how about easy_install -f .   (note a dot there)
I though that will not go online to get data.

On 4/5/06, Phillip J. Eby <p...@telecommunity.com> wrote: