Awkwardness of dest argument for bundle/add-bin?

[sogaiu]

I'm trying out bundle/add-bin and found that I ended up expressing a call with a dest argument like this:

(defn install
  [manifest &]
  (bundle/add-bin manifest 
                  "git-some-janets.janet"
                  # dest
                  "bin/git-some-janets"))

Note the prefix of bin/ for the dest argument.

I think it would be nicer to be able to say:

(defn install
  [manifest &]
  (bundle/add-bin manifest 
                  "git-some-janets.janet"
                  # dest
                  "git-some-janets"))

If this is non-problematic in theory, is it too late to change bundle/add-bin's behavior?

---

On a side note, it looks like bin and bundle are "special" directories under (dyn *syspath*), i.e. probably it's best if people don't create a project that stores their library code in those directories?

There already seem to be some other "special" directories like .cache, .manifests, etc. in my environment.

I wonder whether there could be a .bin and .bundle instead of bin and bundle...thoughts?

Update: Spelling things out a bit differently, adopting a convention like .<name> for all "special" directories might make it easier to avoid accidental use by 3rd parties, be more consistent with the pre-bundle setup, and makes it easier to programmatically operate on "special" vs "non-special" directories under (dyn *syspath*). May be there are some downsides too (possibly breaking some code?) I'm not thinking of.

[bakpakin]

I'm ok with the change for the default of the dest argument for add-bin, but not sure if the hidden directories are really needed. Files in the bin directory are meant to be run and you absolutely can put files in there. The various files in the bundle directory are just Janet modules that you can import. The hidden files are from JPM and are things that you either should need to look at or shouldn't mess with.

[sogaiu]

TLDR; Thanks for your thoughts, perhaps as you seem to be hinting at, it may be unlikely that problems will arise with the current arrangement.

---

I'm going to spell things out a bit more below(, partly for my own understanding).

I take it that ordinarily a developer wouldn't want to be putting library files in bin or bundle (if they knew they were in some sense "special" or "different"). For example, in jpm we can specify something for declare-source, like a directory name, which leads to a subdirectory of that name being created directly beneath (dyn *syspath*). I presume the usual case (assuming one was aware of the design intent for bundle) would be to NOT specify bin or bundle for such a use.

It seems likely that for some time there will be overlapping use of jpm and bundle [1]. Folks who make projects with jpm may not learn about what bundle uses (so soon). If someone unwittingly chooses to put stuff in bundle or bin (via jpm), that might lead to problems, though the chances of this may be rather low. Even if it did lead to some problems, perhaps recovering from them and adjusting might be ok.

The leading dot suggestion was partly about preventing such accidental use / choice in the above sort of case, but also if janet were to need further "special" directories, the aforementioned simple "namespacing-via-leading-dot-or-not" idea might be less problematic than accidentally choosing some name that a developer might have already chosen. Of course, there is nothing to prevent the choice of a name beginning with a leading dot in the future -- no such convention has to exist beforehand, so again, this may be nothing to be concerned over.

With all of that laid out, it seems clearer to me that the necessity is on the low side. I do think it is nicer (for human decisions and unintentional error-making as well as programmatically) to be able to make the distinction (about whether a directory is "special") based on a simple rule, but may be one is unlikely to get that much out of it in this case.

---

[1] May be this is not a good assumption?

[sogaiu]

#1485 is working for me, thanks!