Skip to content

Conversation

mdedetrich
Copy link
Contributor

@mdedetrich mdedetrich commented Mar 2, 2023

So in a project I am working on I noticed the following comment from https://github.com/apache/incubator-pekko-grpc/blob/main/build.sbt#L144-L146, i.e.

// This project should use 'publish/skip := true', but we need
// to be able to `publishLocal` to run the interop tests as an
// sbt scripted test. At least skip scaladoc generation though.

This PR updates publishTask so that it respects publishLocal / skip. The current solution is a bit boilerplatery and is also missing a test however if I am on the right track then let me know and I can update the PR.

Also when the PR is ready I can create an equivalent PR for the 1.8.x branch (not sure if another sbt release for 1.8.x is expected). Either that or we can just cherry pick once this is merged

@mdedetrich mdedetrich force-pushed the make-skip-work-on-publish-local branch 5 times, most recently from 14c94cc to babeba6 Compare March 2, 2023 12:06
log: Logger,
ref: ProjectRef
)(notPublishLocal: () => Unit): Unit = {
if (currentCon == publishLocalConf) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this equality comparison correct for checking if the current publish target is publishLocal or should something else be done?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A more idiomatic way would be to pass the corresponding skip key to publishTask directly and then call it with

    publish := publishTask(publishConfiguration, publish / skip).value,
    publishLocal := publishTask(publishLocalConfiguration, publishLocal / skip).value,

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes that would be nicer, lets see what response I get from sbt maintainer to see if I am on write track and if so I can clean it up later

Copy link
Contributor Author

@mdedetrich mdedetrich Mar 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I just had a quick look at this and I am not sure if this is possible without breaking binary compatibility (which I think is a concern as they appear to be public functions?)

The first issue is that if I change publishTask to `

def publishTask(
    config: TaskKey[PublishConfiguration],
    skipPublish: TaskKey[Boolean]
)

Then this will conflict with an already existing deprecated method (i.e.

@deprecated("Use variant without delivery key", "1.1.1")
def publishTask(
    config: TaskKey[PublishConfiguration],
    deliverKey: TaskKey[_],
): Initialize[Task[Unit]] =
  publishTask(config)

Both methods will have the same type after erasure.

Instead you could define

def publishTask(
    config: TaskKey[PublishConfiguration],
    skipPublish: Boolean
)

To deal with the erasure problem but on the assumption we are dealing with public functions, such a function is out of place in terms of API design. I could make this private, but I would also have to do some more additional changes to the call site since we are not dealing with a TaskKey anymore (naively doing publishTask(publishConfiguration, publish / skip).value doesn't work because the macro cannot expand the .value at that spot).

If I can get rid of the deprecated publishTask function then this change makes perfect sense. @eed3si9n What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can remove methods during 1.x series.

Copy link
Contributor Author

@mdedetrich mdedetrich Mar 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay so you fine leaving the implementation it as is?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay so you fine leaving the implementation it as is?

Yea.

@SethTisue
Copy link
Member

SethTisue commented Mar 2, 2023

after this change, if I publish / skip := true but I don't set publishLocal / skip, does publishLocal publish or not?

will people need to set both in order to get the old behavior? asking because I think the old behavior is what is wanted most of the time

@mdedetrich
Copy link
Contributor Author

mdedetrich commented Mar 2, 2023

Yes I actually was thinking of this, if one sets publish / skip := true to true then I believe it would only apply to publish. This should be fairly easy to fix, i.e. instead of

skip := false

You would have

skip := false
publishLocal / skip := (publish / skip).value, // So we don't break previous behaviour

@mdedetrich mdedetrich force-pushed the make-skip-work-on-publish-local branch from babeba6 to 5187996 Compare March 2, 2023 16:14
@mdedetrich
Copy link
Contributor Author

@SethTisue So I pushed a change with I think should preserve current behaviour as you described

Copy link
Member

@eed3si9n eed3si9n left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall ok with the direction, but we would like a test.

@mdedetrich mdedetrich force-pushed the make-skip-work-on-publish-local branch 2 times, most recently from 9dac9c4 to f81db56 Compare March 3, 2023 15:05
@mdedetrich mdedetrich force-pushed the make-skip-work-on-publish-local branch from f81db56 to 2a332a5 Compare March 3, 2023 15:09
@mdedetrich
Copy link
Contributor Author

@eed3si9n All tests are passing now, let me know if any additional changes are needed

@mdedetrich mdedetrich requested a review from eed3si9n March 3, 2023 16:15
Copy link
Member

@eed3si9n eed3si9n left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@adpi2
Copy link
Member

adpi2 commented Jun 6, 2023

I think this PR introduced a bug: #7288

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants