Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to use multiple groups for local Swift Package #1118

Closed
hainayanda opened this issue Aug 20, 2021 · 9 comments
Closed

Add ability to use multiple groups for local Swift Package #1118

hainayanda opened this issue Aug 20, 2021 · 9 comments

Comments

@hainayanda
Copy link

By default, any Swift Package added via xcodegen will be populated into one group named "Packages". It's not always ideal since in my case, I have 2 groups of packages:

  • Local Packages which contains Application local packages that will be used only by the corresponding apps. These are apps specific features modules.
  • Shared Packages which contains packages from git submodules that are shared via multiple apps that use the submodules. This includes common apps functionality modules, like base networking, remote config, utility, etc.

Using the current xcodegen will put all the packages in the same group and will create confusion for my team. I am using git modules because I need to have access to shared packages and the ability to fix and update them right away instead of updating via Swift Package Manager manually.

Can xcodegen have the ability to configure multiple groups for packages instead of using the default Packages group?

@havebeenfitz
Copy link

havebeenfitz commented Jan 21, 2022

@yonaskolb, Hi! Is this a desired feature? I think I could help and make a PR if you don't mind. I kind of need that too now :)

@yonaskolb
Copy link
Owner

I'm not sure what you mean. Do you mean the Package Dependencies section in the navigator? Xcode automatically builds that from your list of resolved Swift packages. Is there a way to do what you're doing without XcodeGen?

@havebeenfitz
Copy link

havebeenfitz commented Feb 4, 2022

As I understand, it's about the Packages folder on the top controlled by localPackagesGroup. It can only be flat for now, but it would be nice to have the ability to parse and preserve a hierarchy of folders if needed. When you have a lot of local packages, it seems useful.

And when I define the package dependency from path it will create intermediate folders for me

packages:
  AlamofireNetworkClient:
    path: Packages/AlamofireNetworkClient
  AppEnvironment:
    path: Packages/Group2/AppEnvironment
  ...

Something like:

Screenshot 2022-02-04 at 11 45 20

@hainayanda
Copy link
Author

Exactly

@MartinP7r
Copy link

MartinP7r commented Apr 17, 2022

@hainayanda have you tried setting the group via the optional parameter added in #1175?

You might be able to do something like

packages:
  AlamofireNetworkClient:
    path: Packages/AlamofireNetworkClient
    group: Packages/Group1
  AppEnvironment:
    path: Packages/Group2/AppEnvironment
    group: Packages/Group2
  ...

See documentation.

@maxkraev-personal
Copy link

maxkraev-personal commented Apr 17, 2022

Sorry, but it's not working for me. When I set the package like

packages:
  AppFeature:
    path: Packages/Features/AppFeature
    group: Features/AppFeature

or

packages:
  AppFeature:
    path: Packages/Features/AppFeature
    group: Features

or

packages:
  AppFeature:
    path: Packages/Features/AppFeature
    group: Packages/Features

and regenerating the project, the groups are not created, and the package is absent. @John-Connolly, could you please guide me on how to use the configuration? I have createIntermediateGroups set to true on the root level, spec validation doesn't find any mistakes

@hainayanda
Copy link
Author

@hainayanda have you tried setting the group via the optional parameter added in #1175?

You could do something like

packages:
  AlamofireNetworkClient:
    path: Packages/AlamofireNetworkClient
    group: Packages/Group1
  AppEnvironment:
    path: Packages/Group2/AppEnvironment
    group: Packages/Group2
  ...

See documentation.

Already tried that, but it does not work if the group is logical. Is that intentional by design?

@himammz
Copy link

himammz commented Oct 20, 2022

Hi @hainayanda Did you find a solution ?

@hainayanda
Copy link
Author

Hi @himammz it's working, but with some limitations as I mentioned before, it will not work if you want the group to be logical.

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

No branches or pull requests

6 participants