-
Notifications
You must be signed in to change notification settings - Fork 11
Module Packaging Thunderdome
largely historical. See module docs.
May the best bikeshed win.
http://legacy.python.org/dev/peps/pep-0302/
http://docs.racket-lang.org/reference/mzlib_unit.html
http://community.schemewiki.org/?p=scheme48-module-system http://s48.org/1.8/manual/manual-Z-H-5.html
http://gbracha.blogspot.com/2009/06/ban-on-imports.html http://gbracha.blogspot.com/2009/07/ban-on-imports-continued.html
http://www.haskell.org/haskellwiki/Import http://www.haskell.org/haskellwiki/Package_versioning_policy
It shouldn’t be hard for Dev to version her new code. When she writes in a feature, she wants to follow the semantic versioning system and do major updates for breaking changes, minor updates for new interfaces, etc. without having to manually verify that she computed the version number correctly.
Upton just wants a version of his dependency which works with his application. He doesn’t care which version it is, as long as it’s new enough to work and not so new that he has to port his own code forward. He doesn’t want to support two versions, just one.
Filly would like her deployment process to be simple, but also wants to be able to reproduce environments precisely. She uses Puppet/Chef/etc. for deploying, and it’s important to her that a rollout onto dozens or hundreds of servers be repeatable.
Python and Java use ‘import’. Things like Racket and Scheme48 have a configuration language to express the ways that code is connected together. I’d like more of the latter and less of the former in Monte. Being able to support static linking, side-by-side deployment of different module versions in the same process, and parameterized modules are all things that having ‘import’ makes hard, so far as I can tell.
Node.js uses a function called `require`, which gets a instance of the target, possibly cached, executes it, and returns a special name from the target. In particular, if casino.js has a line like `module.exports = caesarsPalace;`, then calling `require(‘foo’)` would return `caesarsPalace`. I like this for a few reasons:
- It makes exports explicit. The things that get exported from a module (and therefore are available for import) are explicitly stated and controlled.
- It separates the steps of getting a thing, and binding that thing to a name. (consider Python’s `import casino` vs Node’s `var theRealCasino = require(‘casino’);`
- It provides a path for extensions to the import mechanism. Consider `require(“casino”, “>=1.0”)`
I don’t know yet.
- Semantic versioning seems good. Haskell’s flavor seems plusgood.
- Statements are incompatible with Monte; we should not have a special magical statement for imports.