Test the mailing list

Hope it will work and that will be able to talk about rest-client here

/J.

Hi guys, I implemented OAuth support on my fork on github of rest-client.
Can you take a look and comment ?

http://github.com/ngw/rest-client

 ngw

Hi,

I have already some things on my todo list but I'll promise to have a
look as soon as the urgent things are done

A.

Thank you so much.
For work reasons I need this stuff sorted out quickly, I will probably need to fork and merge back after some time.
Every feedback is highly appreciated.

ngw

Hi,

I'm looking into packaging rest-client for Debian and Ubuntu, but I
can't seem to find the rest-client releases as tarballs. Are they
available somewhere?

Thank you,
--
| Lucas Nussbaum
| lucas@... http://www.lucas-nussbaum.net/ |
| jabber: lucas@... GPG: 1024D/023B3F4F |

Hi

Why do you need a tarball instead of the gem ?

A.

On 11/12/09 at 18:44 +0100, Julien Kirch wrote:

Hi

Why do you need a tarball instead of the gem ?

See http://pkg-ruby-extras.alioth.debian.org/rubygems.html for the full
background. But basically, we need to be easily able to uncompress it to
build the .debs.

Lucas

Le 11 déc. 09 à 19:17, Lucas Nussbaum a écrit :

On 11/12/09 at 18:44 +0100, Julien Kirch wrote:

Hi

Why do you need a tarball instead of the gem ?

See http://pkg-ruby-extras.alioth.debian.org/rubygems.html for the
full
background. But basically, we need to be easily able to uncompress
it to
build the .debs.

Lucas

Interesting, and very debian-ish !
http://debgem.com/ seems a good alternative to install gems on debian
system and rest-client is available from it.

But if you simply need to decompress it a gem is a tar file which
contains a metadata.gz with the metadata and a data.tar.gz with the
content,
Does it fit your needs ?

A.

On 11/12/09 at 19:37 +0100, Julien Kirch wrote:

Le 11 déc. 09 à 19:17, Lucas Nussbaum a écrit :

On 11/12/09 at 18:44 +0100, Julien Kirch wrote:

Hi

Why do you need a tarball instead of the gem ?

See http://pkg-ruby-extras.alioth.debian.org/rubygems.html for the
full
background. But basically, we need to be easily able to uncompress
it to
build the .debs.

Lucas

Interesting, and very debian-ish !

not really, most of the the other programming languages release
language-agnostic archives.

http://debgem.com/ seems a good alternative to install gems on debian
system and rest-client is available from it.

The goal is to package and support it inside Debian (and Ubuntu), not
just to install it on my system. In the process, it would be de-gemified
(i.e, installed in the normal path for libraries, not into the gem
path).

But if you simply need to decompress it a gem is a tar file which
contains a metadata.gz with the metadata and a data.tar.gz with the
content,
Does it fit your needs ?

Where can I download it using a web browser? Is there a page I could
monitor (automatically) for new releases?
--
| Lucas Nussbaum
| lucas@... http://www.lucas-nussbaum.net/ |
| jabber: lucas@... GPG: 1024D/023B3F4F |

not really, most of the the other programming languages release
language-agnostic archives.

ok, the only languages I used on debian was java and perl and for both
of them I used their specific packaging, but I understand the point.

http://debgem.com/ seems a good alternative to install gems on debian
system and rest-client is available from it.

The goal is to package and support it inside Debian (and Ubuntu), not
just to install it on my system. In the process, it would be de-
gemified
(i.e, installed in the normal path for libraries, not into the gem
path).

But if you simply need to decompress it a gem is a tar file which
contains a metadata.gz with the metadata and a data.tar.gz with the
content,
Does it fit your needs ?

Where can I download it using a web browser? Is there a page I could
monitor (automatically) for new releases?

If you want to download the gem wihout installing it:
- from a browser you can use http://gemcutter.org/gems/rest-client-1.0.3.gem
(http://github.com/qrush/gemcutter/issues/#issue/116 <- it seems a
more direct approach will be available soon)
- or if you have rubygems installed "gem fetch" will download a gem
without installing it

For the monitoring gemcutter don't offer a per-gem feed AFAIK (it
should be trivial to implement, you should perhaps create a ticket for
it?) but for the moment you can grab the general feed at http://feeds.feedburner.com/gemcutter-latest
and filter it ?

If I understand, the resulting package will be distributed through
debian packaging, so there's no point to make it available on github,
isn't it

A.

On 11/12/09 at 20:10 +0100, Julien Kirch wrote:

not really, most of the the other programming languages release
language-agnostic archives.

ok, the only languages I used on debian was java and perl and for both
of them I used their specific packaging, but I understand the point.

http://debgem.com/ seems a good alternative to install gems on debian
system and rest-client is available from it.

The goal is to package and support it inside Debian (and Ubuntu), not
just to install it on my system. In the process, it would be de-
gemified
(i.e, installed in the normal path for libraries, not into the gem
path).

But if you simply need to decompress it a gem is a tar file which
contains a metadata.gz with the metadata and a data.tar.gz with the
content,
Does it fit your needs ?

Where can I download it using a web browser? Is there a page I could
monitor (automatically) for new releases?

If you want to download the gem wihout installing it:
- from a browser you can use http://gemcutter.org/gems/rest-client-1.0.3.gem
(http://github.com/qrush/gemcutter/issues/#issue/116 <- it seems a
more direct approach will be available soon)
- or if you have rubygems installed "gem fetch" will download a gem
without installing it

For the monitoring gemcutter don't offer a per-gem feed AFAIK (it
should be trivial to implement, you should perhaps create a ticket for
it?) but for the moment you can grab the general feed at http://feeds.feedburner.com/gemcutter-latest
and filter it ?

Mmmh, I was looking into something more static, like many projects have.
We have a service that scrapes a specified website and notifies the
maintainer when a new release is available for download. Well, I guess I
could live without it.

The alternative would be for that service to monitor the main github
branch for rest-client. However, releases for rest-client are not being
tagged on gitub currently. Could this be changed? We have a redirector
that allows to transparently monitor github for new tags.

If I understand, the resulting package will be distributed through
debian packaging, so there's no point to make it available on github,
isn't it

Correct.
--
| Lucas Nussbaum
| lucas@... http://www.lucas-nussbaum.net/ |
| jabber: lucas@... GPG: 1024D/023B3F4F |

The alternative would be for that service to monitor the main github
branch for rest-client. However, releases for rest-client are not
being
tagged on gitub currently. Could this be changed? We have a redirector
that allows to transparently monitor github for new tags.

Sure, this will be done

A.

On 11/12/09 at 20:32 +0100, Archiloque wrote:

The alternative would be for that service to monitor the main github
branch for rest-client. However, releases for rest-client are not
being
tagged on gitub currently. Could this be changed? We have a redirector
that allows to transparently monitor github for new tags.

Sure, this will be done

Great!

The "root" branch for rest-client is still adamwiggins/rest-client? (put
differently: who is making the releases?)
The status, as seen by our redirector, can be seen at
http://githubredir.debian.net/githubredir.cgi?author=adamwiggins&project=rest-client

Could you tag the last release, so it would work for me now, instead of
waiting for the next release to happen?

See
http://githubredir.debian.net/githubredir.cgi?author=ln&project=feed2imap
for an example with a correctly tagged project.
--
| Lucas Nussbaum
| lucas@... http://www.lucas-nussbaum.net/ |
| jabber: lucas@... GPG: 1024D/023B3F4F |

Le 11 déc. 09 à 21:13, Lucas Nussbaum a écrit :

On 11/12/09 at 20:32 +0100, Archiloque wrote:

The alternative would be for that service to monitor the main github
branch for rest-client. However, releases for rest-client are not
being
tagged on gitub currently. Could this be changed? We have a
redirector
that allows to transparently monitor github for new tags.

Sure, this will be done

Great!

The "root" branch for rest-client is still adamwiggins/rest-client?
(put
differently: who is making the releases?)
The status, as seen by our redirector, can be seen at
http://githubredir.debian.net/githubredir.cgi?author=adamwiggins&project=rest-client

Could you tag the last release, so it would work for me now, instead
of
waiting for the next release to happen?

See
http://githubredir.debian.net/githubredir.cgi?author=ln&project=feed2imap
for an example with a correctly tagged project.

We're in a transition phase: Adam is the creator but can't allocate
enough time to the project so I'm currently working to replace him as
maintainer (the mailing list being one of the step).
I don't know if Adam's repo will stay the official one when the
transition will be finished, but I'll ask him to tag the latest
release on its repo.

A.

On Fri, Dec 11, 2009 at 12:13 PM, Lucas Nussbaum
<lucas@...> wrote:

The "root" branch for rest-client is still adamwiggins/rest-client? (put
differently: who is making the releases?)
The status, as seen by our redirector, can be seen at
http://githubredir.debian.net/githubredir.cgi?author=adamwiggins&project=rest-client

I actually do tag releases, but I forgot that you have to push them
separately (git push --tags). Just did that so now all the releases
should be tagged properly - the page you linked to seems to be seeing
those correctly.

Adam

On 11/12/09 at 15:37 -0800, Adam Wiggins wrote:

On Fri, Dec 11, 2009 at 12:13 PM, Lucas Nussbaum
<lucas@...> wrote:

The "root" branch for rest-client is still adamwiggins/rest-client? (put
differently: who is making the releases?)
The status, as seen by our redirector, can be seen at
http://githubredir.debian.net/githubredir.cgi?author=adamwiggins&project=rest-client

I actually do tag releases, but I forgot that you have to push them
separately (git push --tags). Just did that so now all the releases
should be tagged properly - the page you linked to seems to be seeing
those correctly.

Hi,

Just to let you know, the librestclient-ruby (we have a policy for
naming ruby library packages, hence the "strange" name) is now packaged
in Debian. It will also be part of the next Debian and Ubuntu releases.
http://packages.qa.debian.org/libr/librestclient-ruby.html
--
| Lucas Nussbaum
| lucas@... http://www.lucas-nussbaum.net/ |
| jabber: lucas@... GPG: 1024D/023B3F4F |

Hi,

A few words on the next moves on rest-client.

Adam has (with great success) created and maintained the library
untill now but can't dedicate enough time for it, so I'm working to
replace him as maintainer.

My goals being:
- no full rewrite: the code is mature and used by projects and other
libraries. As much as possible changes should not break existing API
or code
- integrate features developped on forked versions (the number of
forks is really high, and for the moment users may have to sacrifice a
feature for another depending on the fork they choose which is a
really bad situation from my point of view).
- add some documentation for advanced usages and some unit tests
- not only work on the code but also help the community (this maling
list for example)

Thanks to Adam for trusting me, I hope I'll do some good work

####

Now I have some questions if you can spare me a few minutes:
- beside taps and couchrest, do you now any other largely used
projects that rely on rest-client ? The idea is to use their unit
tests as integration tests for rest-client to be sure I don't
accidently break an API.
- the project have no dependency for the moment, from my java
experience I think it may be considered a good feature as it means no
conflict risk, but is it as valuable in ruby as in java ? I thought
about it because the partial list of mime types in payload may be
replaced by the mime-types gems.
- a more complicated one: the tab indentation. As far as I know, if in
a distant future I change the code indentation to spaces instead of
tabs, it will be a pain for all forkers when they'll want to integrate
any change done after it, as they'll have to apply the change to their
code. On the other side, the current indentation is making (a little)
harder to work on the project, and can make external code integration
more difficult when people start their work by reformating the
existing code. Is there a trick to solve this problem or do you have
some experience on this subject that you could share?

Regards

A.

On Dec 17, 2009, at 11:26 PM, Archiloque wrote:

Hi,

A few words on the next moves on rest-client.

Adam has (with great success) created and maintained the library
untill now but can't dedicate enough time for it, so I'm working to
replace him as maintainer.

My goals being:
- no full rewrite: the code is mature and used by projects and other
libraries. As much as possible changes should not break existing API
or code

I second this. I prefer to refactor minor parts.

- integrate features developped on forked versions (the number of
forks is really high, and for the moment users may have to sacrifice a
feature for another depending on the fork they choose which is a
really bad situation from my point of view).
- add some documentation for advanced usages and some unit tests
- not only work on the code but also help the community (this maling
list for example)

Thanks to Adam for trusting me, I hope I'll do some good work

####

Now I have some questions if you can spare me a few minutes:
- beside taps and couchrest, do you now any other largely used
projects that rely on rest-client ? The idea is to use their unit
tests as integration tests for rest-client to be sure I don't
accidently break an API.

My plan is to integrate it with the OAuth gem (when rest-client is available) to permit file uploads to the OAuth gem. Of course, I need to make file uploads work on rest-client before :p
On the matter, does someon know of any working forks of rest-client with this part implemented ? I forked from http://github.com/francois/rest-client

- the project have no dependency for the moment, from my java
experience I think it may be considered a good feature as it means no
conflict risk, but is it as valuable in ruby as in java ? I thought
about it because the partial list of mime types in payload may be
replaced by the mime-types gems.

I never had a conflict in my life with gems, as far as I remember.

- a more complicated one: the tab indentation. As far as I know, if in
a distant future I change the code indentation to spaces instead of
tabs, it will be a pain for all forkers when they'll want to integrate
any change done after it, as they'll have to apply the change to their
code. On the other side, the current indentation is making (a little)
harder to work on the project, and can make external code integration
more difficult when people start their work by reformating the
existing code. Is there a trick to solve this problem or do you have
some experience on this subject that you could share?

Well, I don't think it's good to keep tabs in the code, spaces are more or less a de facto standard - my editor converts everything automatically.
I also think that it's more likely that the project has new forks instead of people to use old ones.
At least, they fix the tab problem just once, while everybody who forks now has to care about tabs.

ngw

Now I have some questions if you can spare me a few minutes:
- beside taps and couchrest, do you now any other largely used
projects that rely on rest-client ? The idea is to use their unit
tests as integration tests for rest-client to be sure I don't
accidently break an API.

My plan is to integrate it with the OAuth gem (when rest-client is
available) to permit file uploads to the OAuth gem. Of course, I
need to make file uploads work on rest-client before :p
On the matter, does someon know of any working forks of rest-client
with this part implemented ? I forked from http://github.com/francois/rest-client

It's the fork I plan to intregrate first as I use it myself.

- a more complicated one: the tab indentation. As far as I know, if
in
a distant future I change the code indentation to spaces instead of
tabs, it will be a pain for all forkers when they'll want to
integrate
any change done after it, as they'll have to apply the change to
their
code. On the other side, the current indentation is making (a little)
harder to work on the project, and can make external code integration
more difficult when people start their work by reformating the
existing code. Is there a trick to solve this problem or do you have
some experience on this subject that you could share?

Well, I don't think it's good to keep tabs in the code, spaces are
more or less a de facto standard - my editor converts everything
automatically.
I also think that it's more likely that the project has new forks
instead of people to use old ones.
At least, they fix the tab problem just once, while everybody who
forks now has to care about tabs.

Good point, I think I'll reformat de code as soon as external features
integration has been done.

A.

On Dec 19, 2009, at 8:58 PM, Archiloque wrote:

Now I have some questions if you can spare me a few minutes:
- beside taps and couchrest, do you now any other largely used
projects that rely on rest-client ? The idea is to use their unit
tests as integration tests for rest-client to be sure I don't
accidently break an API.

My plan is to integrate it with the OAuth gem (when rest-client is
available) to permit file uploads to the OAuth gem. Of course, I
need to make file uploads work on rest-client before :p
On the matter, does someon know of any working forks of rest-client
with this part implemented ? I forked from http://github.com/francois/rest-client

It's the fork I plan to intregrate first as I use it myself.

Nice, so I broke something, even if all specs pass.

I will start from the beginning and leave tabs.

ngw