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

Permanent development pods #5591

Closed
alejandro-isaza opened this Issue Jul 3, 2016 · 3 comments

Comments

Projects
None yet
4 participants
@alejandro-isaza

alejandro-isaza commented Jul 3, 2016

I have a project with a number of components split into separate repositories. I want to be able to work on the components at the same time as the main project. Currently this can be achieved with development pods (pointing to the local filesystem). But this erases the version information, which is important for the test server.

It would be great if I could mark a pod as a development pod, but at the same time provide a tag for the build server. If I do pod install --development it will checkout submodules or point to the local filesystem but otherwise it will use the tags and behave as it does right now.

I would be happy to contribute to this feature.

@neonichu

This comment has been minimized.

Member

neonichu commented Jul 4, 2016

One way to already achieve this would be to make your Podfile conditional on some environment variable. Depending on its value, you could use development or release Pods.

Could look roughly like this (untested):

def pods
  if ENV['DEV']
    pod 'ReactiveCocoa', :path => ''
  else
    pod 'ReactiveCocoa'
  end
end
@orta

This comment has been minimized.

Member

orta commented Jul 4, 2016

This ^ would still give you a Podfile.lock with relative paths.

In order to achieve this, you would also need to make changes to the lockfile, so that everyone had a consistent lockfile.

A lot of discussion around this this in these issues #2672 and #1010

@segiddins

This comment has been minimized.

Member

segiddins commented Jul 5, 2016

Yeah, I'm going to close this as a duplicate of those issues -- we've simply not seen a great way to handle this yet.

@segiddins segiddins closed this Jul 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment