On Wed, Nov 26, 2014 at 3:25 PM, Nick Wellnhofer <[email protected]> wrote: > I think every parcel needs to have a .cfp file to tell which version of the > Clownfish runtime it depends on.
I don't think we should make that a hard requirement, because it increases the developer cost up front to start a project. A newbie following a Clownfish tutorial shouldn't need to create a parcel file to write "hello world", and an expert shouldn't need to create one when running an experiment or coding up a throwaway. It should be acceptable either to provide a parcel via a parcel directive in a source file, or to omit the parcel altogether. > So the Clownfish compiler could simply walk > the source directories, and as soon as it finds a .cfp file, it can make all > files in that directory part of this parcel. I'm not sure you were implying this, but a parcel file should not apply to directories above it. Parcel files should only be allowed in the primary parcel dir. > If we enforce that all files of a parcel live under a single directory, we > can also make the following simplifications: > > 1. There's no need for `parcel` directives in .cfh files anymore. This would > remove a bit of boilerplate. Both Python and Go base organize packages around directories, but while Go requires package directives in every source file, Python doesn't. So there are precedents or both approaches. I maintain that it's important that parcel files not be mandatory. If there's no parcel file and no parcel directive in any source files, what should the behavior be? Default to parcel "main" version 0? If so, what does that imply when someone attempts to install something from parcel "main"? > 2. .cfp files don't need a unique filename. They could be simply named > `parcel.json`, for example. We've decided to avoid the nested directory problem of Java, but a side effect is that you can't necessarily discover the parcel by looking at the file system -- at least in a "source" directory. So, while I agree that unique names are not technically necessary, I'm not jumping up and down with enthusiasm about normalizing them all to `parcel.json`. > Another consequence is that we either need another directory level under > `core` for Lucy and Clownfish because of the test parcels: > > core/lucy/Lucy/Analysis > core/test/Lucy/Test/TestAnalysis > > Or we put the tests in a separate top-level directory: > > core/Lucy/Analysis > test/Lucy/Test/TestAnalysis That's one approach. If test code remains in a separate parcel, though, the problem of test code not being able to access non-exported symbols from the main parcel has yet to be resolved. Let me float another possibility: test code belongs to the same parcel and lives in the same directory as the parcel source code, but test files are distinguished by a naming convention such as beginning with the string "Test". Two versions of the parcel library are linked: a test version with all the test file objects included, and an installation version with the test objects excluded. I don't think either of these approaches is quite satisfactory yet, so let's keep exploring. Let me also float a possibility I've been thinking about for a while, which is that the output of CFC should be static archives plus headers, rather than C source code plus headers. Perhaps that opens up some options for dealing with test files. > Regarding the include directory layout, maybe we should make a change to my > original proposal inspired by Ruby gems. Instead of putting a parcel's file > in a directory named `parcel-version`, we could create single directory for > all versions of a parcel with subdirectories for each version like: > > include/com.example.foo/1.0.0/parcel.json > include/com.example.foo/2.0.0/parcel.json > > So we wouldn't have to read the whole top-level directory to lookup parcels. > Whether a parcel exists can be decided with a single `stat` call. To find > all the versions of a parcel, only the entries in the parcel's subdirectory > have to be consulted. +1, sounds great! Marvin Humphrey
