https://pantsbuild.org/ logo
Join Slack
Powered by
Hello! We recently realized we have a couple disti...
# general
h
Hello! We recently realized we have a couple distinct goals that all do a similar thing: create an asset from your code and write it to 
dist/
. (
binary
, 
awslambda
, 
setup-py
, and 
bundle
in v1) We’re thinking it would be clearer to consolidate them all into a new goal, possibly named 
./pants build
. We’d love any feedback about this, including what you would think the name 
build
means, e.g. if you would think it means “compile” some library code, for example. Or if you have suggestions for a more apt name.
This consolidation would follow a proper deprecation cycle. We realize it’s disruptive to change things like this. See https://github.com/pantsbuild/pants/pull/10881 for the change. Please feel free to comment here or on the issue 🙂
w
I liked what @aloof-angle-91616 posted, the idea of getting those artifacts by setting up parameters and hopefully being able to extend those using the plugins api to add maybe specific needs.. that’d be sweet. Same goes for that 
publish
target. I’d love to be able to easily put my generated artifact together with my Dockerfile and build that with a single pants command 🙂
👖 1
🔥 1
a
i would love love to see that and/or help to make that happen!
💯 1
j
build
feels like the right name for processes that output artifacts. 
publish
feels like the right name for processes that put artifacts into useful places.
➕ 3
w
we flatten all rules into three specific goals: • 
package
-- generate build artifacts • 
publish
-- ship artifacts to repositories • 
deploy
-- move code to deployed infrastructure
👍 1
i prefer package over build but not strongly, simply because we refer to CI/CD processes as a "build pipeline" and 
package
seems like a specific step in the build process
👍 1
a
--dry-run
is usually an option on many scripts i've seen that publish things. @jolly-midnight-72759 @wonderful-iron-54019 would you accept that option on 
./pants publish
for e.g. just building a wheel without uploading to pypi?
w
definitely would accept that. we actually alias 
setup-py
to 
package
to generate wheel files then just execute the upload during our publish
✍🏻 1
this way we can run the wheel generation in CI/CD without publishing
a
that makes perfect sense! we do the same thing in the pants repo
w
left a comment re the 
--format
enum on the PR as food for thought
👖 2
a
thank you!
j
@aloof-angle-91616 Do you mean 
--dry-run
would build a wheel without uploading it? That would be confusing. I assume 
--dry-run
has no side effects which would not be the case if I understood you correctly.
package/publish/deploy
also works for my lexicographical wetware.
👀 2
One question, is the difference between 
publish
and 
deploy
necessary from 
pants
perspective?
👀 1
w
that's an interesting question
i think there's a huge semantic difference
j
Is 
pants
the right tool for doing deploys? I guess I would prefer a CD service watching repos and "deployment" configurations and doing the deploys for me. In that cause, is 
pants
updating the "deployment" config?
👀 1
a
yes, it would build a wheel without uploading it. usually my perception is that when publishing, the "side effects" would be understood to refer to "actually contacting the repository and pushing a new version" -- this is how 
./pants publish.jvm --dry-run
works in pants v1. the wheel would be created in 
dist/
anyway, which is configurable so you can avoid polluting it if you want
@jolly-midnight-72759 i think it makes sense for pants to handle deploys because then you can publish your wheels even if you don't have any of that for a tiny little project
w
I would prefer a CD service watching repos and "deployment" configurations and doing the deploys for me.
We've largely defined custom targets for things like cloud formation stacks, databricks jobs, etc and invoke the deploy rule on those to push them out
👍🏽 1
🔥 1
a
but we absolutely have a ton of freedom to make pants hand things off to other tools, or accept the input from other tools
w
but usually our 
publish
-able targets are mutually exclusive from our `deploy-`ables
☝🏻 1
👍🏽 1
for us its convenient to distinguish them b/c if there's an issue with 
publish
-ables we usually want to prevent any deploys from going out
✍🏻 1
a
One question, is the difference between publish and deploy necessary from pants perspective?
i tried to define this in my comment on the thread -- i think "publishable" targets are libraries with a 
provides=
parameter, while "deployable" targets are binaries
(this is my thinking, at least. not trying to say it's right)
w
yeah that sounds right to me
a
@wonderful-iron-54019 i'm going to quote you on that last one, that's a great distinction
👍🏼 1
❤️ 1
j
I agree that publishing and deploying are separate.
👍🏼 1
And being able to do everything from the repo does lower friction.
a
i absolutely hadn't considered any of the above until you mentioned it in this thread so still thinking that's just my first reaction
j
This discussion gives me an idea for a new goal: 
ci-status
it reaches out to the testing infrastructure and gives the status of the last (or last few) test run by it. Then you don't need to leave the repo to see if the code you pushed has peeved Jenkins.
💡 1
a
that is something that someone actually presented on at the last bazelconf, but for bazel
i'm not sure what parts would be needed but especially if this is something you've wanted more than once it could be good to just make an issue (even if it's very vague) so we can iterate on it!
👍🏽 1
h
This is super useful feedback. Thank you all for taking the time out of your day to give your thoughts 🙂 Commented on the ticket. Tl;dr, JP was spot on that the target type already controls the type of asset built will be, e.g. a 
.pex
vs. 
.jar
vs. 
.zip
. I don’t think we’d then want a 
--format
flag. I like the idea of 
package
a lot. It describes well what’s going on, better than a vague 
build
. Higher level than 
assemble
🙌🏼 1
5 Views
Open in Slack
PreviousNext
Powered by