Skip to content

Conversation

@frankois944
Copy link

@frankois944 frankois944 commented Nov 4, 2024

Based on #47

  • Using the command line instead of String manipulation
  • Adding local spm can't be done by command line, so I did it manually
  • Adding platforms can't be done by command line, so I did it manually
  • Adding complex package support (like firebase : see tests)
  • Adding toolsVersion
  • simplify the swift build command

See the new tests for new features

To be done : change the way the version of a spm is set, the command line has limited possibility.

markst and others added 8 commits October 27, 2024 13:34
For VersionRange, it's not possible to have a specific one
We need to try/cacth every swift step and print on the ouput the error, it's important for the user
All test are passing except local package
The local package need to be done
we can now use local path, some manual update has been done
all tests are passing
add new test for building and liking Firebase
using triple for specify the build target
you can set multiple product from a dependency like Firebase
need to duplicate the code of remote function
The exception is not forwarded correctly
check case when the list of packages have a empty string
add some comment for the versioning of package
update comment in interface
We can now set the toolsVersion from the plugin
By default, the command line uses the latest swift version available.
By at some cases, it can't work and a specific version need to be set.
@frankois944
Copy link
Author

I added the capability to set the toolsversion.
By default, it's the latest swift version.

It needs to be set at Warning Level or it will be considered as a Error.
set a non null default value for toolsVersion in CompileTask
rollback unwanted commit change
moving all command for updating the manifest to CreatePackageSwift
@frankois944
Copy link
Author

@IlyaGulya Some feedback?

@IlyaGulya
Copy link
Collaborator

@frankois944 sorry, quite busy this week. I hope to take a look this weekend

@tareksabry1337
Copy link

Anything on this? 👀

@frankois944
Copy link
Author

Anything on this? 👀

Still waiting 😶‍🌫️

Copy link
Collaborator

@IlyaGulya IlyaGulya left a comment

Choose a reason for hiding this comment

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

@frankois944
Thanks for the PR!
Sorry for the late response.
Overall, love to see more tests, but I have some concerns about API changes and cli usage approach, so I've left some comments.
Waiting for your response.

val _minIos = notNull<String>()
val _minMacos = notNull<String>()
val _minTvos = notNull<String>()
val _minWatchos = notNull<String>()
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is a breaking change in plugin API.
Is it really necessary to store versions as strings?

Copy link
Author

Choose a reason for hiding this comment

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

I change from a Int to a String; it has too much limitation.
For example, we can't use this kind of version macos = "10.15.1", this is possible to set in the Package manifest.

I don't think it's a big deal, as it's just a type of the input to change.

replace indexOfFirst with contains
move from the CLI to String template
toolsVersion is by default in version 5.6 and not the current compiler version
The current template has been tested ion 5.6 and could not work in the later/earlier version if specified by the user.
@frankois944
Copy link
Author

frankois944 commented Nov 26, 2024

@IlyaGulya I move to the template
The major issue is the format stuck to a specific swift tool version, I put the default version at 5.9.
If the user set another tools version, the manifest can be broken as the API has been changed.

@IlyaGulya
Copy link
Collaborator

@frankois944 do you know if swift tools follow semantic versioning?
Can we be sure that breaking changes happen only on major releases?
I think currently that should not be an issue, we can always support new tools version, API surface relevant to this plugin does not seem to be large

@frankois944
Copy link
Author

@frankois944 do you know if swift tools follow semantic versioning? Can we be sure that breaking changes happen only on major releases? I think currently that should not be an issue, we can always support new tools version, API surface relevant to this plugin does not seem to be large

The Manifest API depends on the swift version declared in the first line.
I didn't follow API evolution, but I think we will see some warning if we have the need to update the template.
We will need to upgrade the template when this version won't be supported by the compiler.
For now, I guess, this template is enough.

@IlyaGulya IlyaGulya merged commit e21cd68 into ttypic:feature/external-dependencies-single-module-experimental Nov 27, 2024
@IlyaGulya
Copy link
Collaborator

@frankois944 merged
Thank you for the contribution!
I will try to finish this draft this weekend and merge to master (and maybe provide a SNAPSHOT build)

@sgozdzik
Copy link

@frankois944 merged Thank you for the contribution! I will try to finish this draft this weekend and merge to master (and maybe provide a SNAPSHOT build)

Thanks for good work with library! Any idea when you will have some time to release some snapshot build?

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