in Pants 2.9.0, the `--dependencies-type` option w...
# general
f
in Pants 2.9.0, the
--dependencies-type
option was deprecated. The docs say:
This option is misleading and not very useful. In the future there will be a more robust way of querying and filtering dependencies.
suggesting doing this in the meanwhile
Copy code
./pants dependencies ::
| xargs ./pants filter --target-type=python_requirement
| xargs ./pants peek | jq -r '.[]["requirements"][]'
Have I missed a clever way to list only 3rd party or only 1st party dependencies in Pants now? 😕
1
e
The filter subsystem is still there. Pants main:
Copy code
$ ./pants --filter-target-type=python_requirement dependencies ::
3rdparty/python#setuptools
3rdparty/python/requirements.txt
3rdparty/python/user_reqs.lock:python-default
So
s/goal/subsystem/
That may not do exactly what you want, but
./pants list --filter-X-Y ..
can replace the old `filter`goal verbatim IIUC.
f
oh of course, thank you, John. This requires a user to know that the 3rd party requirements are represented as
python_requirement
targets which may be fair.
./pants --filter-target-type=python_requirement dependencies ::
This lets user think in higher level entities, perhaps a bit better from the consumer's perspective:
./pants dependencies --type=3rdparty ::
3rd party code may be represented not as
python_requirement
then one would need to do multiple filters. But to be fair, the core Pants
--type=3rdparty
wouldn't know that either. I was looking into adding a new option inside a plugin to inject it into the
dependencies
goal, but was told this won't work, I'd need a new goal for this, which is something I'd like to avoid.
perhaps
--filter-target-type
is after all not that bad 🤔
e
I was really just teeing off your example 2nd line. However you wish to mix and match the tools,
./pants list --filter-XYZ ...
is your
./pants filter ...
-alike.
1