That sounds like a good idea, but in practice, I've learned to shy away
from anything "automagic". As the Zen of Python says, explicit is usually
better than implicit.
With something like CocoaPods, you're going to end up with a handful of
very common, idiomatic use-cases (linking to a library, including a
framework, straight-up .m and .h files, adding bundles, etc), and there are
two ways to make these use-cases accessible to the users:
* bake the use-cases into the language / toolset (make it automagic)
* leave the user to figure it out on their own, but arm them with lots of
examples (the master repo) or tutorials/docs (the wiki)
I've come to prefer the latter, because it familiarizes the user with how
to find the answers on their own (e.g, greping the master repo).
The problem with automagic is that it tends to leave the user dependent on
the tool, and in practice there's never enough magic to cover all cases.
/2cents
On Mon, Jul 2, 2012 at 9:51 PM, LOU Yu Hong <louyuh...@gmail.com> wrote:
I had similar concerns before implementing this change as I dislike magic as well. But I don't consider this feature magic as it is really simple to explain:
If you use it in the podspec CocoaPods will keep it around. If for any reason you want to keep it around just add it to the preserve paths.
I think that the current solution is a good compromise for the following reasons:
- It allows to clean unused subspecs.
- CocoaPods keeps around the files that it actually uses (plus a couple of other files like readmes and licenses).
- It is easy for a user to keep around a file with preserve_paths: there is never an unsupported edge case.
- It keeps the podspecs bit more concise, which never hurts.
- It gives control to the core of cocoapods, we can update the algorithm without changing all the podspecs.
The feature has just been introduced and there are some cases that could be automated as well some fine tuning to do.
I think that we can be more explicit in other ways: for example, the uses cases that you provided could have direct support in the podspec format, so it would be very clear what you are doing and we could handle it in the best possible way.
I would have preferred to have this discussion before implementing it :-) But anyway thanks for sharing your opinion.
> That sounds like a good idea, but in practice, I've learned to shy away from anything "automagic". As the Zen of Python says, explicit is usually better than implicit.
> With something like CocoaPods, you're going to end up with a handful of very common, idiomatic use-cases (linking to a library, including a framework, straight-up .m and .h files, adding bundles, etc), and there are two ways to make these use-cases accessible to the users:
> * bake the use-cases into the language / toolset (make it automagic)
> * leave the user to figure it out on their own, but arm them with lots of examples (the master repo) or tutorials/docs (the wiki)
> I've come to prefer the latter, because it familiarizes the user with how to find the answers on their own (e.g, greping the master repo).
> The problem with automagic is that it tends to leave the user dependent on the tool, and in practice there's never enough magic to cover all cases.
> /2cents
> On Mon, Jul 2, 2012 at 9:51 PM, LOU Yu Hong <louyuh...@gmail.com> wrote:
> Hi,
> Is there a way to set a default preserve_paths?
> Seems like **/*.a should be preserved usually.
> I had similar concerns before implementing this change as I dislike magic
> as well. But I don't consider this feature magic as it is really simple to
> explain:
> If you use it in the podspec CocoaPods will keep it around. If for any
> reason you want to keep it around just add it to the preserve paths.
> I think that the current solution is a good compromise for the following
> reasons:
> - It allows to clean unused subspecs.
> - CocoaPods keeps around the files that it actually uses (plus a couple of
> other files like readmes and licenses).
> - It is easy for a user to keep around a file with preserve_paths: there
> is never an unsupported edge case.
> - It keeps the podspecs bit more concise, which never hurts.
> - It gives control to the core of cocoapods, we can update the algorithm
> without changing all the podspecs.
> The feature has just been introduced and there are some cases that could
> be automated as well some fine tuning to do.
> I think that we can be more explicit in other ways: for example, the uses
> cases that you provided could have direct support in the podspec format, so
> it would be very clear what you are doing and we could handle it in the
> best possible way.
> I would have preferred to have this discussion before implementing it :-)
> But anyway thanks for sharing your opinion.
> On 03/lug/2012, at 20:38, Jason Pepas wrote:
> (speaking as just a user, not a core developer)
> That sounds like a good idea, but in practice, I've learned to shy away
> from anything "automagic". As the Zen of Python says, explicit is usually
> better than implicit.
> With something like CocoaPods, you're going to end up with a handful of
> very common, idiomatic use-cases (linking to a library, including a
> framework, straight-up .m and .h files, adding bundles, etc), and there are
> two ways to make these use-cases accessible to the users:
> * bake the use-cases into the language / toolset (make it automagic)
> * leave the user to figure it out on their own, but arm them with lots of
> examples (the master repo) or tutorials/docs (the wiki)
> I've come to prefer the latter, because it familiarizes the user with how
> to find the answers on their own (e.g, greping the master repo).
> The problem with automagic is that it tends to leave the user dependent on
> the tool, and in practice there's never enough magic to cover all cases.
> /2cents
> On Mon, Jul 2, 2012 at 9:51 PM, LOU Yu Hong <louyuh...@gmail.com> wrote:
>> Hi,
>> Is there a way to set a default preserve_paths?
>> Seems like **/*.a should be preserved usually.
> On Tue, Jul 3, 2012 at 2:08 PM, Fabio Pelosin <fabiopelo...@gmail.com> wrote:
> Hi Jason,
> I had similar concerns before implementing this change as I dislike magic as well. But I don't consider this feature magic as it is really simple to explain:
> If you use it in the podspec CocoaPods will keep it around. If for any reason you want to keep it around just add it to the preserve paths.
> I think that the current solution is a good compromise for the following reasons:
> - It allows to clean unused subspecs.
> - CocoaPods keeps around the files that it actually uses (plus a couple of other files like readmes and licenses).
> - It is easy for a user to keep around a file with preserve_paths: there is never an unsupported edge case.
> - It keeps the podspecs bit more concise, which never hurts.
> - It gives control to the core of cocoapods, we can update the algorithm without changing all the podspecs.
> The feature has just been introduced and there are some cases that could be automated as well some fine tuning to do.
> I think that we can be more explicit in other ways: for example, the uses cases that you provided could have direct support in the podspec format, so it would be very clear what you are doing and we could handle it in the best possible way.
> I would have preferred to have this discussion before implementing it :-) But anyway thanks for sharing your opinion.
> On 03/lug/2012, at 20:38, Jason Pepas wrote:
>> (speaking as just a user, not a core developer)
>> That sounds like a good idea, but in practice, I've learned to shy away from anything "automagic". As the Zen of Python says, explicit is usually better than implicit.
>> With something like CocoaPods, you're going to end up with a handful of very common, idiomatic use-cases (linking to a library, including a framework, straight-up .m and .h files, adding bundles, etc), and there are two ways to make these use-cases accessible to the users:
>> * bake the use-cases into the language / toolset (make it automagic)
>> * leave the user to figure it out on their own, but arm them with lots of examples (the master repo) or tutorials/docs (the wiki)
>> I've come to prefer the latter, because it familiarizes the user with how to find the answers on their own (e.g, greping the master repo).
>> The problem with automagic is that it tends to leave the user dependent on the tool, and in practice there's never enough magic to cover all cases.
>> /2cents
>> On Mon, Jul 2, 2012 at 9:51 PM, LOU Yu Hong <louyuh...@gmail.com> wrote:
>> Hi,
>> Is there a way to set a default preserve_paths?
>> Seems like **/*.a should be preserved usually.
Not at all. I actually feel like this is consistent with the change where
all paths are cleaned by default, and consistency is very important.
The two combos which show consistency are:
* don't clean anything by default, don't preserve anything by default, or
* clean everything by default, but make some intelligent exceptions and
preserve those automatically
so, given this design decision, you are doing a good job of executing it.
the important thing is for your software to have an opinion and stick to
it :)
-jason
On Tue, Jul 3, 2012 at 3:54 PM, Fabio Pelosin <fabiopelo...@gmail.com>wrote:
> I didn't want to sound defensive. Actually, I think that good a discussion
> and reasonable critics are fundamental to improve :-)
> On 03/lug/2012, at 21:37, Jason Pepas wrote:
> Hey, opinionated software and all that :)
> Thanks for working hard on this project.
> -jason
> On Tue, Jul 3, 2012 at 2:08 PM, Fabio Pelosin <fabiopelo...@gmail.com>wrote:
>> Hi Jason,
>> I had similar concerns before implementing this change as I dislike magic
>> as well. But I don't consider this feature magic as it is really simple to
>> explain:
>> If you use it in the podspec CocoaPods will keep it around. If for any
>> reason you want to keep it around just add it to the preserve paths.
>> I think that the current solution is a good compromise for the following
>> reasons:
>> - It allows to clean unused subspecs.
>> - CocoaPods keeps around the files that it actually uses (plus a couple
>> of other files like readmes and licenses).
>> - It is easy for a user to keep around a file with preserve_paths: there
>> is never an unsupported edge case.
>> - It keeps the podspecs bit more concise, which never hurts.
>> - It gives control to the core of cocoapods, we can update the algorithm
>> without changing all the podspecs.
>> The feature has just been introduced and there are some cases that could
>> be automated as well some fine tuning to do.
>> I think that we can be more explicit in other ways: for example, the uses
>> cases that you provided could have direct support in the podspec format, so
>> it would be very clear what you are doing and we could handle it in the
>> best possible way.
>> I would have preferred to have this discussion before implementing it :-)
>> But anyway thanks for sharing your opinion.
>> On 03/lug/2012, at 20:38, Jason Pepas wrote:
>> (speaking as just a user, not a core developer)
>> That sounds like a good idea, but in practice, I've learned to shy away
>> from anything "automagic". As the Zen of Python says, explicit is usually
>> better than implicit.
>> With something like CocoaPods, you're going to end up with a handful of
>> very common, idiomatic use-cases (linking to a library, including a
>> framework, straight-up .m and .h files, adding bundles, etc), and there are
>> two ways to make these use-cases accessible to the users:
>> * bake the use-cases into the language / toolset (make it automagic)
>> * leave the user to figure it out on their own, but arm them with lots of
>> examples (the master repo) or tutorials/docs (the wiki)
>> I've come to prefer the latter, because it familiarizes the user with how
>> to find the answers on their own (e.g, greping the master repo).
>> The problem with automagic is that it tends to leave the user dependent
>> on the tool, and in practice there's never enough magic to cover all cases.
>> /2cents
>> On Mon, Jul 2, 2012 at 9:51 PM, LOU Yu Hong <louyuh...@gmail.com> wrote:
>>> Hi,
>>> Is there a way to set a default preserve_paths?
>>> Seems like **/*.a should be preserved usually.
I don’t think we should always preserve .a files. However, an option would be to see if the user specifies the `library`/`framework` attribute of the spec with a relative path (i.e. inside the pod), in which case it can be added to the files to preserve.
> Not at all. I actually feel like this is consistent with the change where all paths are cleaned by default, and consistency is very important.
> The two combos which show consistency are:
> * don't clean anything by default, don't preserve anything by default, or
> * clean everything by default, but make some intelligent exceptions and preserve those automatically
> so, given this design decision, you are doing a good job of executing it. the important thing is for your software to have an opinion and stick to it :)
> -jason
> On Tue, Jul 3, 2012 at 3:54 PM, Fabio Pelosin <fabiopelo...@gmail.com> wrote:
> I didn't want to sound defensive. Actually, I think that good a discussion and reasonable critics are fundamental to improve :-)
> On 03/lug/2012, at 21:37, Jason Pepas wrote:
>> Hey, opinionated software and all that :)
>> Thanks for working hard on this project.
>> -jason
>> On Tue, Jul 3, 2012 at 2:08 PM, Fabio Pelosin <fabiopelo...@gmail.com> wrote:
>> Hi Jason,
>> I had similar concerns before implementing this change as I dislike magic as well. But I don't consider this feature magic as it is really simple to explain:
>> If you use it in the podspec CocoaPods will keep it around. If for any reason you want to keep it around just add it to the preserve paths.
>> I think that the current solution is a good compromise for the following reasons:
>> - It allows to clean unused subspecs.
>> - CocoaPods keeps around the files that it actually uses (plus a couple of other files like readmes and licenses).
>> - It is easy for a user to keep around a file with preserve_paths: there is never an unsupported edge case.
>> - It keeps the podspecs bit more concise, which never hurts.
>> - It gives control to the core of cocoapods, we can update the algorithm without changing all the podspecs.
>> The feature has just been introduced and there are some cases that could be automated as well some fine tuning to do.
>> I think that we can be more explicit in other ways: for example, the uses cases that you provided could have direct support in the podspec format, so it would be very clear what you are doing and we could handle it in the best possible way.
>> I would have preferred to have this discussion before implementing it :-) But anyway thanks for sharing your opinion.
>> On 03/lug/2012, at 20:38, Jason Pepas wrote:
>>> (speaking as just a user, not a core developer)
>>> That sounds like a good idea, but in practice, I've learned to shy away from anything "automagic". As the Zen of Python says, explicit is usually better than implicit.
>>> With something like CocoaPods, you're going to end up with a handful of very common, idiomatic use-cases (linking to a library, including a framework, straight-up .m and .h files, adding bundles, etc), and there are two ways to make these use-cases accessible to the users:
>>> * bake the use-cases into the language / toolset (make it automagic)
>>> * leave the user to figure it out on their own, but arm them with lots of examples (the master repo) or tutorials/docs (the wiki)
>>> I've come to prefer the latter, because it familiarizes the user with how to find the answers on their own (e.g, greping the master repo).
>>> The problem with automagic is that it tends to leave the user dependent on the tool, and in practice there's never enough magic to cover all cases.
>>> /2cents
>>> On Mon, Jul 2, 2012 at 9:51 PM, LOU Yu Hong <louyuh...@gmail.com> wrote:
>>> Hi,
>>> Is there a way to set a default preserve_paths?
>>> Seems like **/*.a should be preserved usually.
