Jira (PUP-8685) Migrate gemspec info in project_data.yaml to the .gemspec file

2 views
Skip to first unread message

Enis Inan (JIRA)

unread,
May 1, 2018, 5:37:02 PM5/1/18
to puppe...@googlegroups.com
Enis Inan created an issue
 
Puppet / Task PUP-8685
Migrate gemspec info in project_data.yaml to the .gemspec file
Issue Type: Task Task
Assignee: Unassigned
Created: 2018/05/01 2:36 PM
Fix Versions: PUP 4.10.z
Priority: Normal Normal
Reporter: Enis Inan

We currently use packaging's "package:gem" task to build the Puppet gem which adds a lot more complexity than we need (i.e. it builds a gemspec from data in project_data.yaml and then builds the corresponding default gem from it + any platform-specific gems [that might have platform-specific dependences]).

We should have the info. in project_data.yaml in the .gemspec file so that a simple gem build should do the trick.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

Enis Inan (JIRA)

unread,
May 1, 2018, 6:26:02 PM5/1/18
to puppe...@googlegroups.com

Enis Inan (JIRA)

unread,
May 14, 2018, 1:04:03 PM5/14/18
to puppe...@googlegroups.com

Branan Riley (JIRA)

unread,
May 14, 2018, 6:43:04 PM5/14/18
to puppe...@googlegroups.com

Enis Inan (JIRA)

unread,
Jun 29, 2018, 6:57:03 PM6/29/18
to puppe...@googlegroups.com
Enis Inan commented on Task PUP-8685
 
Re: Migrate gemspec info in project_data.yaml to the .gemspec file

After talking this through with Ethan Brown, it looks like we can't just put all of our deps. in the .gemspec and then dynamically compute which ones we need based on the gem platform. The reason we can't do that is b/c the rubygems interface relies on the .gemspec to display all of its runtime deps, so that the .gemspec needs to statically list all of the runtime deps. The current packaging tooling dynamically generated the .gemspec for each platform-specific gem, so that's why we were able to see all of the runtime-deps. for them. See for example https://rubygems.org/gems/puppet/versions/5.5.2-x86-mingw32 vs. https://rubygems.org/gems/puppet/versions/5.5.2.

So unfortunately, we will still need to use the current tooling, and thus still need ext/project_data.yaml. I'm going to try an approach that will also parse the default runtime deps. from there, so that at least we can have ext/project_data.yaml be the single source of truth for those deps as well.

Enis Inan (JIRA)

unread,
Jul 10, 2018, 4:33:03 PM7/10/18
to puppe...@googlegroups.com
Enis Inan commented on Task PUP-8685

This ticket's blocked on figuring out how we ultimately want to build the gem. Do we want to use the existing tooling, and hence ext/project_data.yaml, to create our gem as it is currently done? Or do we want to make the .gemspec itself buildable, taking out all gem-specific stuff from ext/project_data.yaml? The trade-off for the latter is that we will have to declare the gem deps. dynamically, which will not properly show up on the rubygems interface for listing gem dependencies. Or do we want to move towards shipping a single gem instead? Lots of questions.

Enis Inan (JIRA)

unread,
Jul 10, 2018, 4:33:03 PM7/10/18
to puppe...@googlegroups.com
Enis Inan assigned an issue to Branan Riley
 
Change By: Enis Inan
Assignee: Enis Inan Branan Riley

Josh Cooper (JIRA)

unread,
Sep 16, 2019, 2:53:05 PM9/16/19
to puppe...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages