Re: [Tcllib-devel] Commit Access

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

> 
> Fossil actually has a setting which (when active) allows users to
> self-register, which opens the ability to create tickets, but not
> commits.
> Tcllib uses the default, which is "inactive", given that users cannot
> be deleted. Only disabled.
> 
> I will make an account for you. Commit access. Please use branches for
> new code. Any special wishes regarding the account name ?

I always just go by damon (or Damon if that’s the convention) or damoncourtney. I find very people named Damon, so I can generally get by on just the first name. :)


> Heh. These zip packages are used by the various TEApot  tools we write
> at AS, so, it is useful to us, as is.
> They were originally in our perforce, then open-sourced into Tcllib
> about 4 years ago.
> Note, Sean Woods is working on a zip::mkzip package, in the odie
> branch of Tcllib.
> You might wish to coordinate with him. IIRC Sean's code is based on
> something Pat Thoyts wrote, and requires Tcl 8.6. Not sure about
> yours.

Well, I’m definitely not advocating getting rid of what’s there. Just adding to them, I guess. I called my package just a simple “zip” 1.0 with commands in ::zip::*, but they would probably live in the same space as the current commands since that’s already the package name.


> You have to ask Sean about that. He also presented that work in the
> 2014 conference.
> It is more a starkit-support thing in the core, based on a ZIP
> filesystem instead of metakit.

I’ve written multiple VFS layers to deal with archive files, but that’s not this. This is a straight-up utility package for zip files on the order of:

set fp [::zip::open foo.zip w]
::zip::add $fp some_file.txt
::zip::delete $fp some_other_file_in_the_zip.txt
::zip::close $fp
etc…


> And sometimes I despair, given its nature as kitchen-sink, and all
> maintenance falling to me after authors vanish.

So, expanding on the thing I rattled off a little earlier, what if we just built a system around Github (that could be replaced with some other system in the future)? Then, I wouldn’t need commit access to get my packages in, I would just need approval to get my package added to the list (or not, depending on what the user has chosen).

I could foresee a repo at github.com/tcltk/packages <http://github.com/tcltk/packages> that just contains an index detailing packages and where to find them. Most would probably live on Github, but it wouldn’t be difficult to support other platforms. Sadly, supporting our own core.tcl.tk would be the hardest since I don’t think Fossil has a proper API behind it. Luckily, all the major repos are mirrored to Github already anyway.

Github’s API is dead simple. Get a list of releases to get package versions, get the latest if no version is given. Speaking of, why doesn’t tcltk/tcllib have any proper releases? It has tags, which this package manager could use in place of releases, but the releases mechanism seems a bit more purposeful since you’re actually designating a final thing.

That might actually work. Who admins github.com/tcltk? <http://github.com/tcltk?>

D