error of webOb for TG 2.1.4 installation.

[alind]

I am trying to install TG 2.1.4 and getting this error.

Processing dependencies for tg.devtools
error: Installed distribution WebOb 1.0.8 conflicts with requirement
WebOb>=1.1.1

Any hints?

[Alessandro Molina]

I'm sorry for the inconvenience, this is caused by the fact that the
day after the release of TG2.1.4, Pylons 1.0.1 got released and the
two require a different version of WebOb.

We are already working at fixing this, in the mean time you can work
around this issue by installing TG with:

easy_install -i http://www.turbogears.org/2.1/downloads/current/index
tg.devtools

> --
> You received this message because you are subscribed to the Google Groups "TurboGears" group.
> To post to this group, send email to turbo...@googlegroups.com.
> To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
>

[alind]

Thanks. Its working now.

On Dec 15, 1:35 pm, Alessandro Molina <alessandro.mol...@gmail.com>
wrote:

> I'm sorry for the inconvenience, this is caused by the fact that the
> day after the release of TG2.1.4, Pylons 1.0.1 got released and the
> two require a different version of WebOb.
>
> We are already working at fixing this, in the mean time you can work
> around this issue by installing TG with:
>

> easy_install -ihttp://www.turbogears.org/2.1/downloads/current/index

[Christoph Zwerschke]

Am 15.12.2011 09:35, schrieb Alessandro Molina:
> We are already working at fixing this, in the mean time you can work
> around this issue by installing TG with:
>
> easy_install -i http://www.turbogears.org/2.1/downloads/current/index
> tg.devtools

By the way, that's actually not a workaround, but the recommended
installation method anyway.

-- Christoph

[Alessandro Molina]

On Thu, Dec 15, 2011 at 10:17 AM, Christoph Zwerschke <ci...@online.de> wrote:
>
> By the way, that's actually not a workaround, but the recommended
> installation method anyway.
>

The issue is that we have two recommended installations methods.
It depends on which guide you read:

http://www.turbogears.org/2.1/docs/main/DownloadInstall.html#installation-for-the-impatient
Suggests using the private index

while

http://www.turbogears.org/book/part1/install.html#installing-turbogears2
Suggests using pypi

As the book is more recent it is often considered as the way to go.

[Christoph Zwerschke]

Am 15.12.2011 10:28, schrieb Alessandro Molina:
> http://www.turbogears.org/book/part1/install.html#installing-turbogears2
> Suggests using pypi

I think that should be changed, we should always recommend our index for
beginners who need a running system and don't want to bother with
incompatibilites in the latest required packages.

-- Christoph

[Alessandro Molina]

I agree with you,
but I think that new users will probably feel more comfortable with
being able to use pypi, this would also enable "python setup.py
develop" inside a project to install the full TG stack without issues.

That is the reason why I think that setting the precise version number
inside requirements of the TurboGears package would make life easier
for new users. They can even avoid reading the install guide at all
and go with a plain "easy_install tg.devtools" having a working
environment which probably would be perceived as a good thing by
people that just want to give a try to the framework.

[Christoph Zwerschke]

Am 15.12.2011 11:09, schrieb Alessandro Molina:
> That is the reason why I think that setting the precise version number
> inside requirements of the TurboGears package would make life easier
> for new users.

Yes, we discussed this already. Assume we had hardwired a Pylons 1.0
requirement and 1.0.1 brings substantial fixes, would it still be
possible to upgrade or would you get requirement conflict errors? With
the private index and lax requirements a fresh installation works out of
the box, but people still have the freedom to update dependencies from
PyPI. This is particularly important if there is no TG update for month
(which happened in the past) or if people are stuck with older TG
versions when our API changes and they don't find the time to adapt
their applications. They still want to be able to update individual
components if these have important fixes.

-- Christoph

[Alessandro Molina]

On Thu, Dec 15, 2011 at 11:33 AM, Christoph Zwerschke <ci...@online.de> wrote:
> Am 15.12.2011 11:09, schrieb Alessandro Molina:
>>
>> That is the reason why I think that setting the precise version number
>>
>> inside requirements of the TurboGears package would make life easier
>> for new users.
>
>
> Yes, we discussed this already. Assume we had hardwired a Pylons 1.0
> requirement and 1.0.1 brings substantial fixes, would it still be possible
> to upgrade or would you get requirement conflict errors?

Right, you would get a conflict error.
even though I think this is greatly reduced by a frequent release cycle.

> With the private
> index and lax requirements a fresh installation works out of the box, but
> people still have the freedom to update dependencies from PyPI. This is
> particularly important if there is no TG update for month (which happened in
> the past) or if people are stuck with older TG versions when our API changes
> and they don't find the time to adapt their applications. They still want to
> be able to update individual components if these have important fixes.

Can't we provide both?
Nothing prevents us from releasing on pypi a package with frozen
versions and keep the private index with a package that has minimum
versions requirements. I think that this is the way that would make
easy for newcomers to install the framework and possible for experts
to tune it.
It just requires a very little extra effort from us when preparing a
new release.

[Christoph Zwerschke]

Am 15.12.2011 11:50, schrieb Alessandro Molina:
> Can't we provide both?
> Nothing prevents us from releasing on pypi a package with frozen
> versions and keep the private index with a package that has minimum
> versions requirements. I think that this is the way that would make
> easy for newcomers to install the framework and possible for experts
> to tune it.
> It just requires a very little extra effort from us when preparing a
> new release.

I guess the actual difficulties of raw recruits is that they don't
understand the Python packaging system and virtual envs, and may not
even have setuptools or virtualenvs installed. In TG1 we tried to solve
this problem with a tgsetup.py script which also installed setuptools.
But this caused more problems than it solved.

I still think it's better if the docs properly explain and motivate only
one recommended way of installing. If we provide two different methods
or even two different variants of the package, I fear it will evoke
confusion and maintenance trouble.

-- Christoph

[Alessandro Molina]

On Thu, Dec 15, 2011 at 12:20 PM, Christoph Zwerschke <ci...@online.de> wrote:
>
> I guess the actual difficulties of raw recruits is that they don't
> understand the Python packaging system and virtual envs, and may not even
> have setuptools or virtualenvs installed. In TG1 we tried to solve this
> problem with a tgsetup.py script which also installed setuptools. But this
> caused more problems than it solved.
>

I agree, tgsetup.py causes only more confusion.

> I still think it's better if the docs properly explain and motivate only one
> recommended way of installing. If we provide two different methods or even
> two different variants of the package, I fear it will evoke confusion and
> maintenance trouble.
>

I still think that making install process as easy as possible is a
really important issue, but I can see your point.
If we really want to be stuck with the private index only solution we
should update the TG Book as quickly as possible so that people won't
follow the wrong install guide.

And I would also suggest to add to the quickstart template a new
command on setup.cfg like "python setup.py tg-install" that installs
the right TurboGears version for the project from the private index.

So that installing a project is as easy as:

python setup.py tg-install
python setup.py develop

[Christoph Zwerschke]

Am 15.12.2011 12:56, schrieb Alessandro Molina:
> And I would also suggest to add to the quickstart template a new
> command on setup.cfg like "python setup.py tg-install" that installs
> the right TurboGears version for the project from the private index.

Right, I was thinking along these lines, too. The command could also
check for an already installed project whether the right versions of TG
and its dependencies from the private index are installed, and make
recommendations or upgrade/downgrade automatically.

-- Christoph

[Michael Pedersen]

I'm going to interrupt the both of you with this, You're both headed down a path that you don't need to head down.

The problem that we have is not a problem of which piece of documentation is correct (they both should work as stated). The problem is not a case of "we must specify which version we need". The problem is not in the release process (though there is a different, specific problem, there, that I just figured out this morning). 

The problem is that something has changed outside of our system. I did this work for 2.1.1, and it worked. You could do exactly what the book describes, and it worked every time. It did so by modifying setup.cfg (to specify the allow_hosts parameter) and setup.py (to specify dependency_links). The result was a package, published on pypi, that would only use our index when you ran "easy_install tg.devtools" or "easy_install TurboGears2". If you did the easy_install on something else that happened to rely on one of those, it did not.

The end result is that people could build their own index for their own package, giving them the level of control they needed for whatever they chose.

Now, for some reason, the outside has changed. I don't know what, specifically, has changed, but something has. The result is that the install process isn't working the way it did, and people are running into problems. I wish I had the answer. I don't. I'm going to try to find it and fix it this weekend.

Here's what I don't like, and don't see a good reason to do:

* I don't like creating an installer script. If we require more than virtualenv / easy_install, we're doing something wrong, and people will realize this.

* I don't like specifying revisions in the setup.py. Unless we have an extremely good reason (right now, we really don't, not even for the WebOb problem, since if the setup ran the way I got it working, we wouldn't need to do so), we shouldn't be forcing specific revisions on people.

* I don't like having a complex command line for the install. Let's face it "easy_install -i http://www.turbogears.org/2.1/downloads/current/index/ tg.devtools" is a lot more complex than "easy_install tg.devtools".

If anybody can help me figure out why distribute (and now, apparently, setuptools) are both ignoring the setup.cfg file, I would greatly appreciate it. If not, I'll fix it this weekend.

Outside of that, though, let's not make things more complex. Stop trying to lock in revisions. Stop trying to add external tools to install. Stop making people use complex commands. All of these make problems.

Oh, I did mention a problem in the release process, didn't I? Right now, if you look at setup.py, it specifies the "current" URL. It should specify the exact version number, so that people can do "easy_install tg.devtools==2.1.4", and always get 2.1.4 packaging. I'll fix that for the next go around.

-- 

Michael J. Pedersen

My Online Resume: http://www.icelus.org/ -- Google+ http://plus.ly/pedersen

Google Talk: m.ped...@icelus.org -- Twitter: pedersentg

[Alessandro Molina]

I'm agree that if distribute/setuptools cared about the setup.cfg file
of tg whe wouldn't have this issue.
I'm not really proficient with distribute, but as far as I have been
able to see it cares about it only if you have tg.devtools already
installed, not while you are installing it. As I never changed the
version of setuptools that I use, I suspect that it has always been
like this and we just didn't notice it for 2.1.1.

Have you tried asking on the distutils-sig mailing list if the
behavior we expect is the correct one?

[Michael Pedersen]

On Thu, Dec 15, 2011 at 10:19 AM, Alessandro Molina <alessand...@gmail.com> wrote:

I'm agree that if distribute/setuptools cared about the setup.cfg file
of tg whe wouldn't have this issue.
I'm not really proficient with distribute, but as far as I have been
able to see it cares about it only if you have tg.devtools already
installed, not while you are installing it. As I never changed the
version of setuptools that I use, I suspect that it has always been
like this and we just didn't notice it for 2.1.1.

Actually, I was very careful about it. While I don't remember which package it was, I do know that we had a similar type of conflict back then. You had to use our index, or  you would get a newer version of some package that would cause failures.

When I did the fix back then, it worked correctly. Like I said, I don't know what changed, or where it changed, but something outside of our control did change. I just wish I knew what that was.

Have you tried asking on the distutils-sig mailing list if the
behavior we expect is the correct one?

I have not. I don't know why, but I didn't think to do so. I'll do that, worst case, tonight. Today is going to be insanely busy for me as I get ready to leave the current job (tomorrow is last day).

[percious]

Michael,

I think you are missing the point.

easy_install tg.devtools is never going to work reliably.  The best we can do is to create a hudson script to test the install daily (hourly?), and notify us if the install fails.  It seems like the last release (2.1.4) may have missed the critical step of testing the install in a clean environment before it was shipped, which would have caught this WebOb versioning issue.

Why is e_i never going to work reliably?  The public Pypi changes over time and we don't control the vast majority of the packages that TG relies on.  That means that we don't control what dependencies _those_ packages have either.

There are other problems compounding the usage of Pypi.  The Pylons package, for instance utilizes the find_links = http://www.pylonshq.com/download/ option in it's setup.cfg. What does easy_install do with this? As soon as it sees it, it sets the index to pylons' index, which means we can't use any versioning in our own dependency list. It's dumb, it sucks, it's _hard_ to work around, but not impossible. I've asked Ben to take find_links out, but he decided not to. We could try to get setuptools fixed (not likely). So, should we add our own find_links option? Well, I think this just makes the problem worse for downstream projects. For all the releases I have done for TG, I have recreated a custom Pylons package that removes the find_links option. This only works if we maintain a private index.

I've spent HOURS trying to solve this problem.  It's not really solvable.  You can't use easy_install without -i and have reliability.  I wrote basketweaver to make creating private indexes easier.

So, the URL for -i is long.  Here's a new one: http://bit.ly/tg_index  I have not tested this works with easy_install, but I'm guessing they have redirects working properly.

Sorry if this comes off a bit snippy.  I don't think everyone has all the information to make the right choice on this quintessential decision about our framework.  I think that all of the devs, and our users have to keep in mind that TG's strength is also it's greatest weakness.  While it has quite a number of dependencies, it's these dependencies that allow us to do so much with so little.  I think that if our users have arrived at TG, they have already decided that the cost of those dependencies is worth the effort.  Our job is to make that as painless as possible, but it's not possible to solve every problem with a broken setuptools (easy_install) that cannot be updated.

Oh, and for what it's worth. PLEASE don't lock down the dependent package versions.  Our users will want to upgrade their packages without having to modify the deps of TG to do it.  This is another thing that makes TG great.

cheers.

-chris

[Toshio Kuratomi]

On Thu, Dec 15, 2011 at 11:50:44AM +0100, Alessandro Molina wrote:
>
> Can't we provide both?
> Nothing prevents us from releasing on pypi a package with frozen
> versions and keep the private index with a package that has minimum
> versions requirements. I think that this is the way that would make
> easy for newcomers to install the framework and possible for experts
> to tune it.
> It just requires a very little extra effort from us when preparing a
> new release.
>

Just would like to point out that this is either a poor or a very bad
solution depending on how it's implemented. If you have two packages on two
separate, "canonical" sites with different versions (to denote that each
installs different ways) you're going to have people who don't know the
backstory trying to guess at which version is "newer" and installing that.
But that's just the poor implementation. Very bad is if you have two
canonical sites for the package with two different packages with the same
version. Then people who don't know the backstory will install one or the
other and be confused why it doesn't behave as the other one is
documented/like the one that their co-worker installed on his machine, etc.

-Toshio

[Alessandro Molina]

Just for notice, as the private package index long url has always been
the worst issue of having a private package index I registered a short
domain for that purpose. Now it is possible to install tg using:

easy_install -i http://tg.gy tg.devtools
easy_install -i http://tg.gy/214 tg.devtools
easy_install -i http://tg.gy/213 tg.devtools

and so on...

at least as soon as the dns updates for you :)

> --
> You received this message because you are subscribed to the Google Groups
> "TurboGears" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/turbogears/-/LBbjUCpY1IUJ.

[Michael Pedersen]

On Thu, Dec 15, 2011 at 12:53 PM, percious <ch...@percious.com> wrote:

I think you are missing the point.

Most definitely am not missing it. I firmly believed that I had things working reliably. Now I can see that I did not. I just  spent a few hours scouring through distribute, looking at what config files got read, when they got read, and can say that the problem comes from the fact that neither setuptools nor distribute will honor the setup.cfg when it's downloaded.

After the package is installed, on a subsequent run of easy_install, is when the file will be read. Of course, this fails to help us when we're doing the initial installation.

I know that I swore up and down I had it working in the past. It would appear that I was mistaken, and I never did have it working as I thought I did. I don't know how or why it appeared to work in the past, but I was decidedly wrong.

 

easy_install tg.devtools is never going to work reliably.  The best we can do is to create a hudson script to test the install daily (hourly?), and notify us if the install fails.  It seems like the last release (2.1.4) may have missed the critical step of testing the install in a clean environment before it was shipped, which would have caught this WebOb versioning issue.

Actually, saying "never" is a big no-no in my book. I'm tempted to write up a patch for easy_install, and submit it to setuptools and distribute that would allow this to work the way I expected. Well, maybe not how I expected, but at least to work in a way that supports what we need. Not today, though I have opened a ticket to remind me to work on it ( https://sourceforge.net/p/turbogears2/tickets/135/ ). I'll try to do so for 2.2, so that, maybe, we can reduce the commands to install just down to "easy_install tg.devtools".

Furthermore, you're making a pretty big assumption about the testing of the release. That part, above everything else, is what gets under my skin about this email. Here, allow me to show you the release process: http://www.turbogears.org/book/appendices/preprelease.html

It's true that I didn't write down the "do a final install from clean", but that will be rectified for the next docs update (which will happen tomorrow when I fix the easy_install commands). However, I can assure you that that step was done, and would not have caught this problem anyway. How do I know? The problem came about because Pylons 1.0.1 updated the requirement on the version of WebOb. Pylons 1.0.1 was released the day after we released 2.1.4.

Since everything else was working and looked good, perhaps you can employ your crystal ball to tell us when we're going to get a broken release in the future? Mine was broken when I did this release, I'm sorry.

Yes, I'm annoyed by the implications of what you're saying there. I have done everything I can to ensure the release process be smooth, fully documented, maintainable, and reliable, and you pop in after a long time without a message just to say what amounts to "Hey, you guys sucked at this! WTF were you thinking?"

On Thu, Dec 15, 2011 at 1:45 PM, Alessandro Molina <alessand...@gmail.com> wrote:

Just for notice, as the private package index long url has always been
the worst issue of having a private package index I registered a short
domain for that purpose. Now it is possible to install tg using:

easy_install -i http://tg.gy tg.devtools
easy_install -i http://tg.gy/214 tg.devtools
easy_install -i http://tg.gy/213 tg.devtools

and so on...

at least as soon as the dns updates for you :)

Alessandro: If you wish, I can easily update tg.org to handle those redirects, and then incorporate updating them into the release process. Let me know. I'll admit I'd prefer it, but I'm not going to demand it.

-- 

[Alessandro Molina]

On Sun, Dec 18, 2011 at 5:52 AM, Michael Pedersen <m.ped...@icelus.org> wrote:
> On Thu, Dec 15, 2011 at 1:45 PM, Alessandro Molina
> <alessand...@gmail.com> wrote:
>>
>> Just for notice, as the private package index long url has always been
>> the worst issue of having a private package index I registered a short
>> domain for that purpose. Now it is possible to install tg using:
>>
>> easy_install -i http://tg.gy tg.devtools
>> easy_install -i http://tg.gy/214 tg.devtools
>> easy_install -i http://tg.gy/213 tg.devtools
>>
>> and so on...
>>
>> at least as soon as the dns updates for you :)
>
>
> Alessandro: If you wish, I can easily update tg.org to handle those
> redirects, and then incorporate updating them into the release process. Let
> me know. I'll admit I'd prefer it, but I'm not going to demand it.
>

tg.org is actually owned by some company currently.
If you mean turbogears.org I think it would mess with the web site
having the index that points to the last release private index.

Otherwise if you mean setting an url lik
turbogears.org/somewhere/{213,214} and making tg.gy redirect there
instead of having to specify each rewrite, that is fine for me, let me
know where to point the redirect.

[Michael Pedersen]

On Sun, Dec 18, 2011 at 4:12 AM, Alessandro Molina <alessand...@gmail.com> wrote:

tg.org is actually owned by some company currently.

If you mean turbogears.org I think it would mess with the web site
having the index that points to the last release private index.

Actually, it shouldn't have any impact on the website. I'd set up a virtual host on the current server for tg.gy, and add in the rewrite rules there. Shouldn't take but about 10 or 15 minutes.

Not going to force it, I just think it would be good to use and incorporate into the full release process.

-- 

[Alessandro Molina]

Ah ok, you mean managing the tg.gy vhost from the same server.
Ok, let me know when to switch the domain to the turbogears.org ip and
I'll do it.

> --
> You received this message because you are subscribed to the Google Groups
> "TurboGears" group.

[Michael Pedersen]

Okay, I think I've hit all the main points we need. Here's the redirect rules I've made, and they do seem to work just fine. Let me know if you can think of/find something else I should add in.

        RedirectMatch /(\d{1})(\d{1})(\d{1})(.*)? http://www.turbogears.org/$1.$2/downloads/$1.$2.$3/$4

        RedirectMatch /current(.*)? http://www.turbogears.org/2.1/downloads/current/$1

        RedirectMatch / http://www.turbogears.org/

Note that these are live and active right now. If you update your /etc/hosts file, and point tg.gy to 91.121.1.84 , you will get those rewrite rules right now.

When I do this, I can then run "easy_install -i http://tg.gy/current/index tg.devtools" and get a fully functioning installation.

Better rewrite rules or suggestions will be gladly accepted :)

[Alessandro Molina]

On Sun, Dec 18, 2011 at 7:26 PM, Michael Pedersen <m.ped...@icelus.org> wrote:
> Okay, I think I've hit all the main points we need. Here's the redirect
> rules I've made, and they do seem to work just fine. Let me know if you can
> think of/find something else I should add in.
>
>         RedirectMatch /(\d{1})(\d{1})(\d{1})(.*)?
> http://www.turbogears.org/$1.$2/downloads/$1.$2.$3/$4
>         RedirectMatch /current(.*)?
> http://www.turbogears.org/2.1/downloads/current/$1
>         RedirectMatch / http://www.turbogears.org/
>
> Note that these are live and active right now. If you update your /etc/hosts
> file, and point tg.gy to 91.121.1.84 , you will get those rewrite rules
> right now.

Switched the dns record to 91.121.1.84

>
> When I do this, I can then run "easy_install -i http://tg.gy/current/index
> tg.devtools" and get a fully functioning installation.
>
> Better rewrite rules or suggestions will be gladly accepted :)

I think we can shorten it a bit, in the rewrite rules I did I removed
the need for "index" at the end which looks more clean and easy to
remember:

easy_install -i http://tg.gy/214/index tg.devtools
VS

easy_install -i http://tg.gy/214 tg.devtools

also:

easy_install -i http://tg.gy/current/index tg.devtools

VS
easy_install -i http://tg.gy/current tg.devtools

You can actually enforce index inside the rewritten rule as the
packages will be downloaded from turbogears.org and not from tg.gy as
you are rewriting the domain too.

[Michael Pedersen]

Could you share the ones you used? I agree, they look cleaner/neater, so want to see what you did.

--
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbo...@googlegroups.com.
To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.

[Alessandro Molina]

Well mine where quite stupid:

rewrite ^/(.*) http://www.turbogears.org/2.1/downloads/current/index/$1;
rewrite ^/214/(.*) http://www.turbogears.org/2.1/downloads/2.1.4/index/$1;

[Alessandro Molina]

On Sun, Dec 18, 2011 at 9:14 PM, Alessandro Molina
<alessand...@gmail.com> wrote:
> Well mine where quite stupid:

"where" was off course a "were", but as I'm unable to use a keyboard
I'll never be able to write something that makes sense :D

[Michael Pedersen]

Okay, some good news from all of this. I've updated every place on the site that said anything about doing "easy_install tg.devtools" to reference the current URL for the installation. I've updated the builds on Jenkins to include the URL. In And, as you can see if you go there, they are all working.

Now, we can at least say we have the docs right. Hopefully, we'll eventually manage to get a patch into setuptools and distribute to fix the underlying problems.

--
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbo...@googlegroups.com.
To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.

[Alessandro Molina]

I saw you left them with /index at the end, was there any issue removing it?
I really thing it makes a lot easier to remember the url avoiding it.

[Michael Pedersen]

The easy_install will work without it, but it gives some ugly looking errors. I'll get rid of the need tomorrow night. Pretty sure I just need to switch to some RewriteMatch rules for Apache to make it something I'm happy with.

I just think people should be able to use http://tg.gy/214 as a substitute for http://www.turbogears.org/2.1/downloads/2.1.4/ personally, so am trying to make it work in the general case. It might not be used that way, but I really like the idea.

[Alessandro Molina]

On Wed, Dec 21, 2011 at 5:51 AM, Michael Pedersen <m.ped...@icelus.org> wrote:
> The easy_install will work without it, but it gives some ugly looking
> errors. I'll get rid of the need tomorrow night. Pretty sure I just need to
> switch to some RewriteMatch rules for Apache to make it something I'm happy
> with.
>

Just reporting that I tried starting a new project with:

easy_install -i http://tg.gy/current tg.devtools

and it fails.
It works only if I specify "/index" after "current"

[Michael Pedersen]

We have something weird going on then. I just ran it myself, and it worked. I tried making changes to the apache config, but have, I think, reverted all of them.

Could you try again and let me know if it works for you now?

--
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbo...@googlegroups.com.
To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.

[Alessandro Molina]

On Mon, Jan 2, 2012 at 6:08 PM, Michael Pedersen <m.ped...@icelus.org> wrote:
> We have something weird going on then. I just ran it myself, and it worked.
> I tried making changes to the apache config, but have, I think, reverted all
> of them.
>
> Could you try again and let me know if it works for you now?
>

No luck,
it still doesn't work :/

http://pastebin.com/v6cmGTRu

[Michael Pedersen]

Okay, I still can't replicate the problem you were showing, but I can come close to it. Whenever I was running the easy_install, it would produce an error message early on, but proceed anywyay (couldn't find the URL, but then it appeared to follow the redirects, and it worked).

I've changed the Redirect statements in the config, and things now seem to work properly. Here's what they look like:

        RedirectMatch /(\d{1})(\d{1})(\d{1})(.*)? http://www.turbogears.org/$1.$2/downloads/$1.$2.$3/$4

        Redirect /current/ http://www.turbogears.org/2.1/downloads/current/index/

        RedirectMatch ^/current(.*)? http://www.turbogears.org/2.1/downloads/current/$1

        RedirectMatch / http://www.turbogears.org/

For me, right now, it installs without producing any 404s at all, and the access logs show that as well. Let me know if this works for you?

--
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbo...@googlegroups.com.
To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.

[Alessandro Molina]

On Tue, Jan 3, 2012 at 5:08 AM, Michael Pedersen <m.ped...@icelus.org> wrote:
> Okay, I still can't replicate the problem you were showing, but I can come
> close to it. Whenever I was running the easy_install, it would produce an
> error message early on, but proceed anywyay (couldn't find the URL, but then
> it appeared to follow the redirects, and it worked).
>

Now it seems to work correctly /current but not /214

[Michael Pedersen]

Okay, I saw similar behavior as for /current. I've changed it, and no longer get that initial 404. Can you try again with that "easy_install -i http://tg.gy/214 tg.devtools" and tell me your results?

--
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to turbo...@googlegroups.com.
To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.

[Alessandro Molina]

I changed the doc to point to http://tg.gy/current instead of
http://tg.gy/current/index/ as it is easier to remember
(http://sourceforge.net/p/turbogears2/tg2docs/ci/2a4328e3a042c0fb5357792e138154c34e9d7086/).

This is also related to the fact that an user reported today that
install following the docs didn't work due to the fact that
http://tg.gy/current/index/ gives a 404.

[Michael Pedersen]

Okay, I just ran through and updated the Redirect rules again. Simplified in quantity, though less pleasant to read. The results are that they are now just these:

        RedirectMatch ^/(\d{1})(\d{1})(\d{1})(/index)?(.*?)$ http://www.turbogears.org/$1.$2/downloads/$1.$2.$3/index$5

        RedirectMatch ^/(current)(/index)?(.*?)$ http://www.turbogears.org/2.1/downloads/current/index$3

        RedirectMatch / http://www.turbogears.org/

After doing so, I ran the following commands, and all of them install TG without issue of any sort (no strange 404s, no strange errors, just straight installations inside of a virtualenv):

easy_install -i http://tg.gy/214/index/ tg.devtools

easy_install -i http://tg.gy/214/index tg.devtools

easy_install -i http://tg.gy/214/ tg.devtools

easy_install -i http://tg.gy/214

easy_install -i http://tg.gy/current/index/ tg.devtools

easy_install -i http://tg.gy/current/index tg.devtools

easy_install -i http://tg.gy/current/ tg.devtools

easy_install -i http://tg.gy/current tg.devtools

So, I know they're working the way we wanted them to finally. Unless there's some new and different way that I don't know about (I hope not?)

[Michael Pedersen]

And now I've realized another (small) change to make things even easier.

easy_install -i http://tg.gy/ tg.devtools

that's it. It works, and you can get the full install that easily.