Tcl Extension Repository
rene
I know this topic comes again and again.
But after struggling with building extensions myself here are my
thoughts.
- after many years tcl still have no accepted central repository, but
many attempts are made (see <http://wiki.tcl.tk/16925>)
- ActiveState has done a great deal in providing ActiveTcl, but as a
developer I need sometimes the sources or debug versions too
- building extensions is sometimes tricky
- extension sources are cluttered around the net
- current versions of popular extensions are not tagged
- tcl/tk development is coordinated by the TCT-> why not also managing
of extensions?
Before writing a TIP here are my proposal..
- Build a summary of extensions (see end of <http://wiki.tcl.tk/
16925>) as a special TIP with:
- current version number
- how to get the sources (ftp, http, cvs, svn) as "clickable" or
"copy&paste" text
- where to report bugs
- Like in TIP 16 each extension get a TCT member assigned. We can put
this also in a special TIP.
He is only responsible to check (may be after each new tcl version)
if the given informations are still correct.
- Developers can append new extensions in a special section. The TCT
include or reject with a new tcl version.
- Accept only extensions with a version tag or version file.
Future:
- Extend the summary with links to binary versions
- Build and/or test extensions for new tcl versions and provide the
binaries
- Maintain (at least make it buildable) abandoned extensions
rene
sleb...@gmail.com
Rather than start Yet Another Extension Repository I'd prefer to see
the tcl community support ActiveState's teacup/teapot system.
Currently it just barely works but I'm sure it can be made to evolve
into something nice.
Larry W. Virden
> - after many years tcl still have no accepted central repository, but
> many attempts are made (see <http://wiki.tcl.tk/16925>)
So, what is your idea on making this version work?
The primary thing missing from all repository efforts before is that a
repository requires a lot of time, energy, and resources to start and
maintain.
> - ActiveState has done a great deal in providing ActiveTcl, but as a
> developer I need sometimes the sources or debug versions too
Why? I am not arguing that you don't - but it would be useful to
detail why you need the sources.
For instance, I know that I sometimes need the sources for debugging a
problem in the extension. I also need the sources sometimes to
understand how something works.
When making a proposal, give detail on why you need something so that
others understand the motivation.
And the debug versions (perhaps with profiling and memory checking,
etc. turned on) are indeed a very valuable need. Another thing that
is needed is the documentation and demos for the packages.
> - building extensions is sometimes tricky
yes it is - and having the source will accentuate that. How would a
repository of source solve that problem?
> - extension sources are cluttered around the net
> - current versions of popular extensions are not tagged
What does "tagged" mean in this instance?
> - tcl/tk development is coordinated by the TCT-> why not also managing
> of extensions?
This is the biggest problem I have with your idea. It's taken the TCT
five years to get out the latest version of Tcl - and there are major
Tcl core components in the pipeline that need to be coordinated in the
near future. I don't believe that there are enough resources in the
TCT to handle extensions as well. And I think it would be a mistake to
add another 20 or 30 people to the TCT.
>
> Before writing a TIP here are my proposal..
>
> - Build a summary of extensions (see end of <http://wiki.tcl.tk/
> 16925>) as a special TIP with:
> - current version number
> - how to get the sources (ftp, http, cvs, svn) as "clickable" or
> "copy&paste" text
> - where to report bugs
Why put this information in as a TIP? What's the benefit here? I
suppose the argument is having a central location - but you could use
a page on wiki.tcl.tk for that.
> - Like in TIP 16 each extension get a TCT member assigned. We can put
> this also in a special TIP.
Not enough TCT resources to do this - even the limited amount of work
you detail below.
> He is only responsible to check (may be after each new tcl version)
> if the given informations are still correct.
What are they checking - that the authority location for the source is
correct? That could be automated. You don't need a human to do that.
If you mean to check to see if the version is correct and that it
builds and works wtih the latest tcl, that's a lot of work, and would
require someone who tracks and understands how the extension works.
It would seem to me that having the author of the extension be
responsible for this would be better. See Perl's CPAN for a real world
example of that.
> - Developers can append new extensions in a special section. The TCT
> include or reject with a new tcl version.
> - Accept only extensions with a version tag or version file.
So then most of the major extensions - itcl, tcljava, etc. would not
be included, since they don't typically do versions, etc.
>
> Future:
>
> - Extend the summary with links to binary versions
created and maintained by whom?
> - Build and/or test extensions for new tcl versions and provide the
> binaries
who is going to do this work?
> - Maintain (at least make it buildable) abandoned extensions
>
by whom?
I hope you don't mind me saying this - but this seems like another
case of someone asking for some other group to provide a free service
for their use.
Things might be more likely to happen, and might more likely contain
the services wanted, if someone who wanted such a thing just started
doing it.
Remember that there is no development team for Tcl. Tcl development
hinges on contributions from the tcl community using it.
Larry W. Virden
> Rather than start Yet Another Extension Repository I'd prefer to see
> the tcl community support ActiveState's teacup/teapot system.
> Currently it just barely works but I'm sure it can be made to evolve
> into something nice.
I know I've spent about a year submitting bug reports and questions
relating to teapot/teacup.
I hope that others who have tried it and have found problems or need
questions answered are doing the same. However, I know I am seldom
seeing such questions on the activetcl mailing list or here, which are
the two places I'd normally expect to see such things.
I have been assuming that either people were using teacup without a
problem, or had no need for a repository, since otherwise, specific
bug reports would be submitted to bugs.activestate.com about problems
encountered...
rene
Larry W. Virden schrieb:
> So, what is your idea on making this version work?
The TCT only maintains a list of links to sources.
The list is on a central, never changing place.
Repositories like teacup can use this list to get the sources, build
binaries, etc.
>
> The primary thing missing from all repository efforts before is that a
> repository requires a lot of time, energy, and resources to start and
> maintain.
Yes, but if each developer send a mail to TCT like:
Package XYZ <version number> <command to get source>
it is almost no time for each.
> Why? I am not arguing that you don't - but it would be useful to
> detail why you need the sources.
To build binaries when no precompiled exists, p.e. I use tcl under
IRIX.
> For instance, I know that I sometimes need the sources for debugging a
> problem in the extension. I also need the sources sometimes to
> understand how something works.
> And the debug versions (perhaps with profiling and memory checking,
> etc. turned on) are indeed a very valuable need. Another thing that
> is needed is the documentation and demos for the packages.
Exactly. Therefore the link to the sources.
> yes it is - and having the source will accentuate that. How would a
> repository of source solve that problem?
It does not solve this problem. That is what teacup etc. are for.
> > - current versions of popular extensions are not tagged
> What does "tagged" mean in this instance?
Vesioning. p.e. try to get the sources for itcl/itk 3.4 as it is
shipped with ActiveTcl.
> > - tcl/tk development is coordinated by the TCT-> why not also managing
> > of extensions?
>
> This is the biggest problem I have with your idea. It's taken the TCT
> five years to get out the latest version of Tcl - and there are major
> Tcl core components in the pipeline that need to be coordinated in the
> near future. I don't believe that there are enough resources in the
> TCT to handle extensions as well. And I think it would be a mistake to
> add another 20 or 30 people to the TCT.
The TCT should not manage extensions. It should only manage the list
of extension source links!
Say we have around 100 extensions. So each TCT member get around 10
and check on announcement
of each new tcl version the availablility of these extensions. This is
not much time for each of them.
Also if common knowledge new version should be given to the TCT by the
developers.
No need to search the web of the current state of your favorite
extension.
> > - current version number
> > - how to get the sources (ftp, http, cvs, svn) as "clickable" or
> > "copy&paste" text
> > - where to report bugs
>
> Why put this information in as a TIP? What's the benefit here? I
Central, well known place which stays there forever (at least I think
so). Moderated by the TCT.
Each developer knows this location well. May be also including this
list into the tcl source tree is possible.
> suppose the argument is having a central location - but you could use
> a page on wiki.tcl.tk for that.
Who is responsible for the content?
> > - Like in TIP 16 each extension get a TCT member assigned. We can put
> > this also in a special TIP.
> Not enough TCT resources to do this - even the limited amount of work
> you detail below.
Check 10 links may be twice a year is to much?
> What are they checking - that the authority location for the source is
> correct? That could be automated. You don't need a human to do that.
Okay. No problem. If it is to much time the TCT can the task automate.
> If you mean to check to see if the version is correct and that it
> builds and works wtih the latest tcl, that's a lot of work, and would
> require someone who tracks and understands how the extension works.
> It would seem to me that having the author of the extension be
> responsible for this would be better. See Perl's CPAN for a real world
> example of that.
May be teacup will be our CPAN. But when? And how do they get the
sources?
May be Jeff can explain this.
> > - Developers can append new extensions in a special section. The TCT
> > include or reject with a new tcl version.
> > - Accept only extensions with a version tag or version file.
>
> So then most of the major extensions - itcl, tcljava, etc. would not
> be included, since they don't typically do versions, etc.
Yes. But the TCT can ask them to do so.
It is still a bit different if these question comes not from a single
user.
> > Future:
That is not included in the proposal. Sorry about the wrong direction
here.
rene
rene
sleb...@yahoo.com schrieb:
> Rather than start Yet Another Extension Repository I'd prefer to see
> the tcl community support ActiveState's teacup/teapot system.
> Currently it just barely works but I'm sure it can be made to evolve
> into something nice.
list. No more.
rene
Larry W. Virden
> I propose here only a central, maintained extension source link
> list. No more.
>
Seems like this could be something stored in a database (say sqlite)
and some tcl automation written to check at least that links still
exist, and when some problem found, an email could be sent to the
email address associated with the extension.
Perhaps a person willing to take on such a thing could even set up
some incoming mail filters so that updates could be emailed.
Note that I used to provide just this sort of thing - as the old
timers know I used to update on a regular basis a "catalog" of
extensions, applications, etc.
My problem was several fold. 1. I didn't have anything automated. 2.
Discovery of new information was pretty much left up to me going out
and looking for info, if I wanted the latest and greatest - very
seldom was I contacted about new or updated items. Eventually, the
multiple-thousand entries just grew to be too large to handle by
myself. I recruited help, but that never really worked out.
Also, a similar setup used to be located at http://www.tcl.tk/ however
it too grew stale for a variety of reasons.
However, if someone determined to commit time and resources wanted to
take on this sort of thing and to do it right, I think it would be a
useful resource.
Donald G Porter
> ... here are my proposal..
>
> - Build a summary of extensions (see end of <http://wiki.tcl.tk/
> 16925>) as a special TIP with:
> - current version number
> - how to get the sources (ftp, http, cvs, svn) as "clickable" or
> "copy&paste" text
> - where to report bugs
Are you looking for GUTTER? http://wiki.tcl.tk/gutter
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Kevin Walzer
I don't use teacup at all. When I need an extension, I grab the package
at the appropriate spot or build my own. What's wrong with just doing that?
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Joe English
>I know this topic comes again and again.
>But after struggling with building extensions myself here are my
>thoughts.
>
>- after many years tcl still have no accepted central repository, but
>many attempts are made (see <http://wiki.tcl.tk/16925>)
>- ActiveState has done a great deal in providing ActiveTcl, but as a
>developer I need sometimes the sources or debug versions too
>- building extensions is sometimes tricky
>- extension sources are cluttered around the net
>- current versions of popular extensions are not tagged
>- tcl/tk development is coordinated by the TCT-> why not also managing
>of extensions?
For the last point: extensions are best managed by their respective
authors and maintainers. It's generally a _good_ thing that the TCT
stays out of this.
>Before writing a TIP here are my proposal..
No need to to write a TIP, or even a proposal -- just go ahead
and do it!
Unless of course you meant "I propose that *somebody else*
do the following...", in which case the proposal suffers from
the same fatal flaw as all of the previous plans for building
a Tcl Extension Repository that ended up going nowhere.
However, the GUTTER catalogue might address some of the items
on your wishlist; see <URL: http://www.flightlab.com/~joe/gutter/ >:
>- Build a summary of extensions (see end of <http://wiki.tcl.tk/
>16925>) as a special TIP with:
> - current version number
The gutter catalog tracks the complete release history
for extensions (at least, it tracks them as well as I am able;
historical data prior to 2005 is still missing for several
extensions).
> - how to get the sources (ftp, http, cvs, svn) as "clickable" or
>"copy&paste" text
Where available, I include links to the upstream source repositories
(CVS, SVN, Darcs, GIT, etc.). For projects hosted on SourceForge
(as many are) there's no explicit link, but you know what to do there :-)
> - where to report bugs
I don't keep track of that; perhaps I should.
>- Like in TIP 16 each extension get a TCT member assigned. We can put
>this also in a special TIP.
> He is only responsible to check (may be after each new tcl version)
>if the given informations are still correct.
I watch a couple different sources for release announcements,
including comp.lang.tcl and freshmeat.net; I've got a cron
job that periodically polls the Last-Modified: date of package
homepages and pings me when something changes; and there are
a few extension authors who are kind enough to notify me
directly when they make a new release (this isn't a requirement
for getting listed in the catalog, but it's appreciated.)
I update the database as soon as I become aware of a new release,
you can watch <URL: http://www.flightlab.com/~joe/gutter/news.html >
to stay informed. Also available as an Atom feed.
>- Developers can append new extensions in a special section. The TCT
>include or reject with a new tcl version.
Again, it's really best if the TCT stays out of the management
of individual extensions. And it's _especially_ important that
extension release schedules remain decoupled from the core Tcl
release schedule.
>- Accept only extensions with a version tag or version file.
Not sure what you mean here.
>Future:
>
>- Extend the summary with links to binary versions
>- Build and/or test extensions for new tcl versions and provide the
>binaries
ActiveState's TEAPOT does an admirable job of building, testing,
and providing binaries.
>- Maintain (at least make it buildable) abandoned extensions
That's probably asking too much. Orphaned packages are
best adopted by someone who uses them. If nobody needs them --
or at least if nobody needs them badly enough to to take on the
responsibility of future maintenance -- then there's not much
anyone can (or should!) do.
That said, ActiveState _has_ taken on this responsibility for
a number of orphans, and their work is appreciated.
--Joe English
sleb...@gmail.com
> rene wrote:
> >I know this topic comes again and again.
> >But after struggling with building extensions myself here are my
> >thoughts.
>
>
> I update the database as soon as I become aware of a new release,
> you can watch <URL:http://www.flightlab.com/~joe/gutter/news.html>
> to stay informed. Also available as an Atom feed.
>
About GUTTER. I really wish you'd get in touch with the tcl.tk domain
maintainer to get GUTTER under it's umbrella. Kind of like the wiki.
Perhaps gutter.tcl.tk? GUTTER is nice but that URL is hard to remember.
Keith Nash
> I know I've spent about a year submitting bug reports and questions
> relating to teapot/teacup.
>
> I hope that others who have tried it and have found problems or need
> questions answered are doing the same. However, I know I am seldom
> seeing such questions on the activetcl mailing list or here, which are
> the two places I'd normally expect to see such things.
>
> I have been assuming that either people were using teacup without a
> problem, or had no need for a repository, since otherwise, specific
> bug reports would be submitted to bugs.activestate.com about problems
> encountered...
I've reported a couple of bugs recently (as Larry knows). Teacup is a good
system, but I think it is not widely used at the moment because:
(1) to use it, you must get Teacup from ActiveTcl; but
(2) most (all?) of the extensions that you can fetch with Teacup are
provided with ActiveTcl itself
You can use Teacup to keep up to date, but the ActiveTcl releases are of
such high quality that it is seldom necessary to fetch the latest releases.
I expect that Teapot repositories other than ActiveState's will emerge, for
extensions that are not part of the quality-assured ActiveTcl distribution;
however, one feature that is not yet adequately covered by Teapot is
documentation and demos - if I want an extension other than simply to run
pre-existing code, I will always want the documentation and demos, and
(sometimes) the source too.
Keith.
Larry W. Virden
> I've reported a couple of bugs recently (as Larry knows).
Yes, there have a half dozen people who have been exercising teacup.
I've not even tried to set up teapot (The server side of things)
myself...
> (1) to use it, you must get Teacup from ActiveTcl; but
> (2) most (all?) of the extensions that you can fetch with Teacup are
> provided with ActiveTcl itself
Actually, two things here. 1. teacup allows you not only to get the
extensions with activetcl, but a number of new extensions as well, and
2. teacup also allows you to get the updated extensions that
activestate has included in its repository. Well, I guess there is
also 3. ActiveTcl 8.5.x won't come with any extensions - you are
expected to get them all via teacup. So certainly that will change
things.
In _my_ mind, it would really be worthwhile for everyone using
activetcl 8.4 to try out teacup and to learn how it works, given the
critical role it is about to play in your use of the distribution...
> however, one feature that is not yet adequately covered by Teapot is
> documentation and demos - if I want an extension other than simply to run
> pre-existing code, I will always want the documentation and demos, and
> (sometimes) the source too.
Yes, you are right. Another good reason for people to be using teacup
right now - that way, if there are other missing, critical functions,
they can be added into activestate's feature request queue if
submitted to http://bugs.activestate.com/
rene
Larry W. Virden schrieb:
> My problem was several fold. 1. I didn't have anything automated. 2.
> Discovery of new information was pretty much left up to me going out
> and looking for info, if I wanted the latest and greatest - very
> seldom was I contacted about new or updated items. Eventually, the
> multiple-thousand entries just grew to be too large to handle by
> myself. I recruited help, but that never really worked out.
> Also, a similar setup used to be located at http://www.tcl.tk/ however
> it too grew stale for a variety of reasons.
>
> However, if someone determined to commit time and resources wanted to
> take on this sort of thing and to do it right, I think it would be a
> useful resource.
So my idea to let this someone the TCT and encourage developers to
announce new version at a central point.
rene
rene
Kevin Walzer schrieb:
> I don't use teacup at all. When I need an extension, I grab the package
> at the appropriate spot or build my own. What's wrong with just doing that?
itk, etc)
are AFAIK not versioned any more.
rene
rene
Joe English schrieb:
> For the last point: extensions are best managed by their respective
> authors and maintainers. It's generally a _good_ thing that the TCT
> stays out of this.
> No need to to write a TIP, or even a proposal -- just go ahead
> and do it!
htis for my personal work. But I would like to see something general.
> Unless of course you meant "I propose that *somebody else*
> do the following...", in which case the proposal suffers from
> the same fatal flaw as all of the previous plans for building
> a Tcl Extension Repository that ended up going nowhere.
My proposal is to find a central place where developer put links to
new versions
and user can find the sources of extensions of a particular tcl
version.
>
> However, the GUTTER catalogue might address some of the items
> on your wishlist; see <URL: http://www.flightlab.com/~joe/gutter/ >:
>
> The gutter catalog tracks the complete release history
> for extensions (at least, it tracks them as well as I am able;
> historical data prior to 2005 is still missing for several
> extensions).
Great work. But how can we convince people to send you new versions
and make new versions trackable. p.e. ActiveTcl is providing itcl/itk
3.3. But no
such version can be found in the repository.
>
> > - how to get the sources (ftp, http, cvs, svn) as "clickable" or
> >"copy&paste" text
>
> Where available, I include links to the upstream source repositories
> (CVS, SVN, Darcs, GIT, etc.). For projects hosted on SourceForge
> (as many are) there's no explicit link, but you know what to do there :-)
May be you can here provide the cvs command to get the files.
> > - where to report bugs
> I don't keep track of that; perhaps I should.
May be as a simple "mailto" link.
>
> >- Like in TIP 16 each extension get a TCT member assigned. We can put
> >this also in a special TIP.
> > He is only responsible to check (may be after each new tcl version)
> >if the given informations are still correct.
>
> I watch a couple different sources for release announcements,
> including comp.lang.tcl and freshmeat.net; I've got a cron
> job that periodically polls the Last-Modified: date of package
> homepages and pings me when something changes; and there are
> a few extension authors who are kind enough to notify me
> directly when they make a new release (this isn't a requirement
> for getting listed in the catalog, but it's appreciated.)
>
> I update the database as soon as I become aware of a new release,
> you can watch <URL: http://www.flightlab.com/~joe/gutter/news.html >
> to stay informed. Also available as an Atom feed.
I do it now. Thank you.
rene
rene
Keith Nash schrieb:
> I expect that Teapot repositories other than ActiveState's will emerge, for
> extensions that are not part of the quality-assured ActiveTcl distribution;
> however, one feature that is not yet adequately covered by Teapot is
> documentation and demos - if I want an extension other than simply to run
> pre-existing code, I will always want the documentation and demos, and
> (sometimes) the source too.
would
make me happy.
rene
Jeff Hobbs
> On Sep 7, 9:40 pm, Keith Nash <k...@citizenearth.com> wrote:
>> (1) to use it, you must get Teacup from ActiveTcl; but
>> (2) most (all?) of the extensions that you can fetch with Teacup are
>> provided with ActiveTcl itself
>
> Actually, two things here. 1. teacup allows you not only to get the
> extensions with activetcl, but a number of new extensions as well, and
> 2. teacup also allows you to get the updated extensions that
> activestate has included in its repository. Well, I guess there is
> also 3. ActiveTcl 8.5.x won't come with any extensions - you are
> expected to get them all via teacup. So certainly that will change
> things.
>
> In _my_ mind, it would really be worthwhile for everyone using
> activetcl 8.4 to try out teacup and to learn how it works, given the
> critical role it is about to play in your use of the distribution...
These are important points that I just want to echo. ActiveTcl 8.5 will
rely more on obtaining packages from the repository.
We also intend to see the teapot expanded to see extensions that have
never been included in ActiveTcl. At this time though we are focused on
making sure everything "just works" before expanding it.
>> however, one feature that is not yet adequately covered by Teapot is
>> documentation and demos - if I want an extension other than simply to run
>> pre-existing code, I will always want the documentation and demos, and
>> (sometimes) the source too.
>
> Yes, you are right. Another good reason for people to be using teacup
> right now - that way, if there are other missing, critical functions,
> they can be added into activestate's feature request queue if
> submitted to http://bugs.activestate.com/
Again, good points. More extensions is higher on the list than
integration of docs and demos, but we realize those are useful as well.
Jeff
rene
Jeff Hobbs schrieb:
> We also intend to see the teapot expanded to see extensions that have
> never been included in ActiveTcl. At this time though we are focused on
> making sure everything "just works" before expanding it.
> Again, good points. More extensions is higher on the list than
> integration of docs and demos, but we realize those are useful as well.
As said before, I only suggested a way to get the extension sources.
Will be such a feature in teacup?
It would be nice because a link or one liner could do this.
Otherwise I see the "future" is already there.
My result of this poll is to use the "gutter" for informations,
and get extensions from "teacup". Great news so far.
rene