Re: [Tcllib-devel] Commit Access

[Damon C. <da...@tc...>]

> The package repository discussion isn't new, but you are reflecting a flawed point that needs be addressed by the community at large.

Oh, I know it’s not a new thing. This particular windmill has been tilted at more than once, but if I recall, it’s never been taken on as a project with actual core resources. While the core tends to move glacially, when someone cares about something, the needle moves.

For me, it’s just something that always comes up when I go to write code in Tcl. Invariably, I need some package, and I have to go grub around and find one. Even Tcllib doesn’t ship with the core, so most of the standard, useful stuff one might need still has to be gotten by downloading a .tar.gz, unpacking it, and sticking it somewhere. Blech.


> I say quite honestly that I have no issue with the community building a package repo. If it had one, we might have based ActiveTcl's on top of it. As it was, we had to engineer the whole thing, and a lot of pieces have been open sourced from it.
> 
> However, the key aspect is that it takes a lot of effort (both human and machine) to maintain a repo. We have many machines running 24x7x365x10 years to support this. Even the npm you refer to is itself primarily backed by a company that has received funding to drive the system (offering things like "private repos", something the teapot has had for ... 8+ years?).

All true. NPM is now funded, and they need it. Keeping servers up and running can be expensive.

But, let’s be honest here. We’re not talking about Node.js. We’re talking about Tcl. We’re never going to see that kind of uptake. And if we did, we would solve that problem then. What we’re talking about building is something that’s for US to use. WE need this, not anyone else. No one else cares anymore.

And, yes, running servers can sometimes be a pain, but rather than move to Github, we moved all development to our own core.tcl.tk server, and it kicks along doing its thing just fine.


> The gutter tried to kickstart it, but it's the long term effort and maintenance that needs either really dedicated people with lots of time on their hands (you in the audience that qualify - please raise your hands!), or a well-funded foundation (Tcl lacks that), or ... a company.
> 
> ​Especially with .tm and pure Tcl stuff, the whole TEA system could be reengineered, but it will take a concerted effort to get traction.

Any more than core.tcl.tk already uses? We’re talking about a web server serving out plain .zip files. For the kind of traffic I would expect, the maintenance wouldn’t be that incredible, I don’t think. Don’t think I haven’t considered doing it all myself (who hasn’t?). I’ve owned tclhome.com for more than decade, and I originally got it to build just such a thing.

But Gutter is an example of exactly what will happen with something that is not built and pushed from the core out. It will get no traction. Without a command that is built right into Tcl (and accompanying command-line utility, but not one or the other), you won’t GET any traction.

Look at Go. Google understands this. They built it right into the language from the start, even using Github out of the box.

go get github.com/golang/example/hello
OR
import "github.com/golang/example/stringutil”

Could someone else have built a package repository for Go? Sure. Would anyone have used it? Maybe. But it certainly would have taken a lot of time and effort to get traction.

No, we’re not Google. But neither are we going to be receiving that kind of attention. Hell, maybe we should just write a package manager that can pull repos straight from Github the way Go did. Let Github serve up our packages. All we really need is a package file included in each repo that tells what dependencies and stuff you need. Then we don’t need a server.

But then, we could have done that with the core repos as well, but we chose our own server. Why? Why Fossil and our own servers instead of something more standard? But if we seriously can’t muster the resources to have a package repository on our own, we still need one and just let someone else host it. But it still needs to be in the core to gain any movement.

None of this is new. Just a particular burr that has crept back into my saddle after years and years of hunting down and downloading .tar.gz files every time I need to build something useful.

D