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

Update OSX install part #215

Open
svx opened this Issue Apr 10, 2015 · 10 comments

Comments

4 participants
@svx
Member

svx commented Apr 10, 2015

Update docs about how to install plone on osx

@svx svx added the 99 tag: Plone 5 label Apr 10, 2015

@svx svx referenced this issue Apr 25, 2015

Closed

Plone 5 meta ticket #198

18 of 22 tasks complete

@svx svx added the sprint label Jul 13, 2015

@svx

This comment has been minimized.

Show comment
Hide comment
@svx

svx Aug 13, 2015

Member

@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 ?

Member

svx commented Aug 13, 2015

@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 ?

@jensens jensens added 99 tag: sprint and removed sprint labels Dec 10, 2015

@svx

This comment has been minimized.

Show comment
Hide comment
@svx

svx Feb 1, 2017

Member

@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.

Member

svx commented Feb 1, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@svx

svx Feb 1, 2017

Member

@polyester maybe do you have any suggestions ?

Member

svx commented Feb 1, 2017

@polyester maybe do you have any suggestions ?

@polyester

This comment has been minimized.

Show comment
Hide comment
@polyester

polyester Feb 1, 2017

Member

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.

Member

polyester commented Feb 1, 2017

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.

@svx

This comment has been minimized.

Show comment
Hide comment
@svx

svx Feb 1, 2017

Member

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

Member

svx commented Feb 1, 2017

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

@stevepiercy

This comment has been minimized.

Show comment
Hide comment
@stevepiercy

stevepiercy Feb 1, 2017

Contributor

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.

Contributor

stevepiercy commented Feb 1, 2017

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.

@svx

This comment has been minimized.

Show comment
Hide comment
@svx

svx Feb 1, 2017

Member

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. :)

Member

svx commented Feb 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@svx

svx Feb 1, 2017

Member

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. :)

Member

svx commented Feb 1, 2017

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. :)

@stevepiercy

This comment has been minimized.

Show comment
Hide comment
@stevepiercy

stevepiercy Feb 1, 2017

Contributor

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.

Contributor

stevepiercy commented Feb 1, 2017

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.

@svx

This comment has been minimized.

Show comment
Hide comment
@svx

svx Feb 1, 2017

Member

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.

Member

svx commented Feb 1, 2017

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.

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