First proposed change to prepare for `non-target specs`: rename

Spec

to

AddressSpec

. Why? We don’t want to expand the current definition of

Spec

to include files - it’s a very useful abstraction as is, e.g. that we have logic for

SingleAddress

. At the same time, “specs” is a very useful namespace to describe your specifications for what you want to run against. We would have

AddressSpec

, and

FileSpec

(maybe

DirectorySpec

?). All of these things are `Spec`s. This is a more sound model than something like

Spec

,

File

, and

Directory

, which are all

PositionalArg

.

PositionalArg

is an implementation detail - the real core idea is that this is a specification for something to run against. -- Thoughts and/or opposition?

is there a subtype relationship here? i.e. is

TargetSpec

eventually going to be a subclass of a new abstract class

Spec

that is different from the class currently called

Spec

?

Yes, we’ll have an abstract superclass

Spec

and

AddressSpec

and

FileSpec

would be subclasses Conceptually, a

Spec

is a specification of something to run Pants against. That specification can come in different forms, e.g.

src/python/pants/util:strutil

or

src/python/pants/util/strutil.py

A rule could request either

Specs

,

AddressSpecs

, or

FileSpecs

depending on what interface they want to provide. (Possibly, we decide they need to support all 3 interfaces. Unclear, but we can defer that.)

ok, that makes sense to me, and I think that rename you're talking about is fine

fine with that.

@witty-crayon-22786 would we need to do it via a deprecation cycle where we have both

Spec

as an alias of

AddressSpec

or we can do this without deprecation because the engine isn’t public API? (Although, Spec is used by V1 too)

um. unknown.

Technically, no, it’s not

yea, they're not.