RejectedSoftware Forums

Sign up

Proposal: single-file packages, or SFPs


When dealing with large libraries including multiple files, sub-packages, and so on, dub is well-designed and easy to use. There is one target audience, however, where the user interface could be simpler: packages with only a single file.

The current choice offered is either to make one repository for every single-file package (e.g. my own embd), or to lump together several often unrelated packages into one repo (e.g. the great arsd). The former option is clunky, and the latter requires users to download and compile several modules they won't need. Another option is needed.


An SFP is a folder named example with a single file inside named example.d (not including .git, etc). Somewhere in the file will be a comment like so:

     ...what would be in package.json...

This file could be automatically generated by:

$ dub init --sfp example
    create folder example
    create file example/example.d


Here's some additional ideas:

  • Requiring that the packages be sfp/[name] in the repository?
  • Adding support for gist and dpaste?
  • An option to generate a symlink in the parent folder:
  	- example
    	  - example.d
  	- example.d -> example/example.d

School's about to start, so I'll be slow, but I'm willing to work on it.


Re: Proposal: single-file packages, or SFPs

We had a discussion about this topic some time ago, but I can't find anything now. But there have been similar proposals involving a specially formatted comment or using pragma directives. Another (seamless but more limited) approach was to scan the list of import statements and automatically infer dependencies (+ probably some additional means to do fine tuning). In general I think support for single file projects is a good idea, but I'm not really sure yet which is the best way to go about it.

However, registering single-file packages in the public registry is something that I would likely exclude as a possibility, as the benefit of saving on a single additional file doesn't really justify the additional implementation/maintainance/complexity costs. That is, especially considering that creating the separate git repository for a project that is needed for registration should easily outweigh the effort needed to create a separate package.json file.

Having said that, I need to put some serious thought into this topic to clear my head up, and, because I'm currently still very busy with other things, I just wanted to quickly post my initial thoughts instead of staying silent until that has happened.

TL;DR Worthwhile feature, but the design details should be carefully verified from all possible angles before putting out an implementation.