Should

pants package

validate internal dependencies? I have a scenario of:

> ls
projA/
  dir/
    main.py
projB/
  dir/
    tools.py
> cat projA/dir/main.py
import projB.dir.tools as tools
<rest of script>

Now

projB/dir/tools.py

has been deleted so this import will fail but a

pants package projA::

succeeds in building the related

pex_binary

. Is this expected behaviour?

by default

unowned_dependency_behavior = "warn"

so pants will show a warning when the import couldn't be resolved and successfully build a pex

But the difference here is that

projB.dir.tools

isn’t a dependency that could be owned, that namespace is actually invalid as the file it points to has been deleted. Should that not cause an ImportError?

import error where? it will definitely cause an import error in your code when you try to run it

On run yes, but it doesn’t occur during a

pants package

- does

package

not validate dependencies like this?

pants has a very wide understanding of dependencies, you can depend on

files

or

resources

or

docker_image

, all these can be dependencies. There is no validation or special treatment of python dependencies

you can set

unowned_dependency_behavior=error

if you want it to throw an error. From the perspective of the internals,

projB.dir.tool

isn't "unownable" as it could be a valid package

Okay, that makes sense. Although surely a

pants package

would be installing it if it were a valid package and this would have opportunity to vaildate/fail?

I'm not sure what you're talking about,

pants package

doesn't install anything

Not so much installing as baking in dependencies - first-party/third-party wheels for instance are contained within the .pex file once built, correct? So when resolving dependencies, would it not be looking to also contain this

projB.dir.tools

?

again, it's trying to resolve the dependencies, then it can't find the package, prints the warning and proceeds with building the pex without the package if you want to make it an error, then you need to set

unowned_dependency_behavior

to error

Ah then sorry for the confusion - as I’m not getting such a warning, but I think I’m blocking it by other means