documentation icon indicating copy to clipboard operation
documentation copied to clipboard

Update OSX install part

Open svx opened this issue 10 years ago • 10 comments

Update docs about how to install plone on osx

svx avatar Apr 10 '15 14:04 svx

@smcmahon do we have already something like 'best practices' if people want to install Plone via the UI on OSX ?

I mean for dependencies, if people do not use the old binary installer.

There are lots of different options and I am not sure which to use in in docs:

  • Homebrew
  • MacPorts
  • NixPkgs

does someone has an opinion on that ?

svx avatar Aug 13 '15 11:08 svx

@smcmahon ping :)

Besides the horrible question about which options for dependencies, do we need that at all ?

I mean if you are not a developer, 'just' for playing you could use the vagrant box or even the docker container.

And if you are a developer you have a preference anyway, right ?

What we could do is the same as we do for Operating Systems, which means we use the sphinx add on 'os example' and 'just' write three different examples.

svx avatar Feb 01 '17 13:02 svx

@polyester maybe do you have any suggestions ?

svx avatar Feb 01 '17 14:02 svx

I'm usually of the "one option, if possible, and maybe give a link to others" family; although I have no clue how the relative % of these solutions is in the OS X/Plone world. If it's 50% homebrow 50% Macports then give both options, if it's 80/20 just give one... Nix people are probably clever enough to sort stuff out themselves.

Maybe hold a poll on community.plone.org? The poll plugin is enabled, so that should work.

polyester avatar Feb 01 '17 16:02 polyester

Yeah, I think we could skip NIX, if you use it, you know how to install dependencies.

svx avatar Feb 01 '17 16:02 svx

For Pyramid we've gone with homebrew for macOS. http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/install.html#for-mac-os-x-users

Note: We have not yet adopted the new spelling of Apple's desktop operating system in Pyramid docs, but we may do so in the future.

stevepiercy avatar Feb 01 '17 18:02 stevepiercy

I think in this question it is a bit more complicated than go with one or the other, there are fundamental differences between MacPorts and Homebrew, how they work and so on.

It is also not recommend to install both on the same system, at least this was the case some time ago.

Since we also should think about ppl who may already have one or the other installed we should IMHO provide instructions for both.

This is btw. also one of the reasons why the 'new macOS' installer never made it into production.

Like I wrote above:

I mean if you are not a developer, 'just' for playing you could use the vagrant box or even the docker container.

And if you are a developer you have a preference anyway, right ?

Which leads us to developers as main audience for which we IMHO should provide both. :)

svx avatar Feb 01 '17 19:02 svx

If you 'force' user to install 'yet' another package management system you are IMHO not a nice person :).

Because besides wasting disk space, you also forcing them to keep another system up to date and to learn it. :)

svx avatar Feb 01 '17 19:02 svx

I don't think there's a problem with two package management systems. The problem comes from installing the same package with two different package managers, then wondering, "What the heck just happened?" I've been there.

I think that it is fine to choose one package manager to get something written and useful. Add other package managers in the future. Subject to availability of the people writing the documentation.

For Pyramid docs, we went with homebrew because the authors use it, know it, and were available to write about it. If someone who actually uses macports were to write the docs for it, we would accept it, but we haven't seen any interest in it. It was a simple matter of available labor.

stevepiercy avatar Feb 01 '17 19:02 stevepiercy

I don't think there's a problem with two package management systems. The problem comes from installing the same package with two different package managers, then wondering, "What the heck just happened?" I've been there.

This is one possible reason, we do not know what packages people already have installed with one manager, this could lead to problems, in the worst case to a unsuable system which would be not that nice :).

Like I said we are discussing that already for some time and till now there are valid reasons (for us) why we not decided on one or the other.

And I also do not see the problem of writing that down for two, this is not too time consuming and we have a sphinx add-on to make it look nice, which we already use for exactly this sort of stuff.

svx avatar Feb 01 '17 20:02 svx