Curious about `package.st` file ... about tonel

[estebanlm]

well... right now is pretty useless.
the rational for it was:
a) I do not want to trust in the subdir name.
b) I want a way make possible to coexist packages and regular dirs (then we need to "mark" them in someway... something like the .package extension in filetree)
c) I want to be able to store also package metadata (package comments, etc.). Which are for the moment just "envisioned" for Pharo, but it will take time to arrive.

But... purposes a-b are a failure because I discovered monticello implementation of package name validation is very naive and it receives a package name which is just a plain string (I guess that's the reason why you ended adding a .package extension to filetree).
Anyway I was planning a refactor of #canReadFileNamed: to fix that, but then there is backward compatibility, etc. to take into account :/

So now my idea is to implement a second mechanism on monticello that validates better, but keep the old one for older versions... a mess ;)

Other solution is just to resign that functionality and drop support for it, but in the long way I think we will need that.

[dalehenrich]

... okay ... I actually have a use for including package metadata in the very short term ... basically when you "copy" a source tree out of a git repository (primary) into another repository like svn, you'd like to be able to trace the source back to the original git version, so I was thinking that I'd stash the commit SHA into the package.st file ... and for now it would write only for now ... anyway I agree that not relying on the directory name is a good thing ... although it becomes an additional point of pain/validation if a user does the copy by hand:) ... I think I mentioned before that in the first 6 months of FileTree, i think I spun through 6 different formats before finally settling on one ... I think that most of the Filetree implementations will still read them ...

You could add some info to the package.st indicating how the file was written and then a reader can use that meta data to decide how to read/interpret the rest of the data ... that way we'll have an early adopter reader for handling older formats and then the latest and greatest which will be much easier to tweak ...