Operations on package-inferred-system

[Eric Timmons]

On Thu, Jul 28, 2016 at 11:54 PM, Faré <fahree at gmail.com> wrote:
> On Thu, Jul 28, 2016 at 12:48 PM, Eric Timmons <etimmons at mit.edu> wrote:
>> I *really* like using package-inferred-system for defining systems,
>> but I often find it doesn't behave as I expect when performing
>> operations on it. I'm curious if these behaviors are intended or if
>> the implementation is just incomplete.
>>
>> I approach package-inferred-system as a way of automatically finding
>> dependencies between files and on third-party systems for a given
>> system I'm writing. Under the hood, I know it makes a new system for
>> every source file, but I consider that just an implementation detail
>> and that when I refer to the primary system, I really mean everything
>> that logically belongs to that system and not just the source files
>> declared in the system's :components option. (Perhaps this assumption
>> just needs to be adjusted on my end).
>>
>> The difference between expectation and reality often manifests itself
>> in two places for me:
>>
>> + When I'm trying to distribute my system with a non-monolithic
>> operation. E.g. `(asdf:perform 'asdf:concatenate-source-op
>> :some-package-inferred-system) results in only the files explicitly
>> declared in the system's :components option being concatenated.
>> (Similar things happen with compile-bundle-op).
>>
>> + `(asdf:load-system :some-package-inferred-system :force t)` results
>> in only the files explicitly declared in the system's :components
>> option being reloaded.
>>
>> I was planning to write my own system class to address these issues,
>> but figured I should see if this is even intended behavior before
>> doing that =).
>>
> Indeed, this suggests that plan classes and bundle operations should
> probably be able to accept a force / force-not argument (or the
> equivalent for bundle operations) intermediate between t and :all,
> such as :by-primary, that forces traversal or non-traversal based on
> the primary system name.
>
> I'm not willing to write it, but I'm willing to review it if and when
> you do. This probably requires a patch to ASDF itself. Extra props to
> you if you find a nice extension protocol that allows to move most of
> that code outside of ASDF itself.

Apologies for letting this languish for so long. Real life and work
consumed all my cycles for a while.

I'm happy to work on this. Before getting started though, I'd like to
get some more feedback on what the default behavior should be. It
seems odd that if someone else wants to bundle my system they need to
know that it's a package-inferred-system and pass the correct keyword
arguments to OPERATE. I think the principle of least surprise would
dictate that bundling a package-inferred-system :a would bundle all of
its inferred children as well since that's presumably what the
developer intended (I can't think of a great reason to bundle just the
parent). A corner case here though is what if :a/b is passed to the
bundle op by the user. If :a/b isn't a top-level system should the
default be to bundle just :a/b, :a/b and :a/b/*, or :a and :a/* ? I
don't have a good answer there.

Admittedly, I can't really make the same argument about `:force t`
when using LOAD-SYSTEM, because presumably if you're reloading
something you're hacking on it and should know that it's a
package-inferred-system. However, the part of me that loves symmetry
thinks reloading :a and :a/* is the right thing to do and that the new
value accepted for :force would stop that behavior.

-Eric