Use --no-site-packages by default #3

Closed
haplo opened this Issue Jul 29, 2013 · 4 comments

Comments

Projects
None yet
2 participants
@haplo

haplo commented Jul 29, 2013

--system-site-packages is considered bad practice, the whole point of virtualenv is isolation. Is there a good reason to have it as default?

@tkf

This comment has been minimized.

Show comment
Hide comment
@tkf

tkf Mar 7, 2014

Owner

Thanks for the comment. I'll answer it even though it is very late :)

The purpose of python-environment.el is automation of install process, not isolation. So, the default behavior should be "use the packages installed in system site-package if there are". Of course, you are free to remove that option if you prefer to install packages in an isolated environment. That's why that variable is a configurable.

Owner

tkf commented Mar 7, 2014

Thanks for the comment. I'll answer it even though it is very late :)

The purpose of python-environment.el is automation of install process, not isolation. So, the default behavior should be "use the packages installed in system site-package if there are". Of course, you are free to remove that option if you prefer to install packages in an isolated environment. That's why that variable is a configurable.

@haplo

This comment has been minimized.

Show comment
Hide comment
@haplo

haplo Mar 7, 2014

Thanks for the response. I appreciate the configurability, that is definitely a nice thing to have, but virtualenv defaults to --no-site-packages since version 1.7 released Nov 2011. My worry is that changing the default here may be confusing.

haplo commented Mar 7, 2014

Thanks for the response. I appreciate the configurability, that is definitely a nice thing to have, but virtualenv defaults to --no-site-packages since version 1.7 released Nov 2011. My worry is that changing the default here may be confusing.

@tkf

This comment has been minimized.

Show comment
Hide comment
@tkf

tkf Mar 7, 2014

Owner

There are two kinds of "users" for this package:

  • package authors --- authors of a package which depends on python-environment.el
  • package users --- users of the package written by the package authors.

I think it is ideal if package users have no need for caring what python-environment.el does --- or even knowing it is installed. Package authors just let package users know that they need a Python command called virtualenv. Remember that package author could write a package that is useful non-Python programmers. Then sometimes it is hard to install some Python packages (e.g., you need Python header file for C extension). In that case, package author could just tell package users that "if you get error XXX then run sudo apt-get install python-YYY." (You might think that "then why not let people install python packages by themselvs?" But If this python library YYY is one of ten dependencies of the Emacs Lisp package, then it still makes sense to use python-environment.el to automate most of the installation). In this case, you need --system-site-packages. Also, pip install sometimes requires building C extension. If you have a package that is already build for your OS, using pip install is just waste of energy.

Besides, I don't see reason why --system-site-packages should not be default for app installation. For sure it is bad idea for development but the main purpose of python-environment.el is not development. You could write a package for Python development but in that case, you just have to override the virtualenv command. python-environment.el is aware of that and has API for that.

Owner

tkf commented Mar 7, 2014

There are two kinds of "users" for this package:

  • package authors --- authors of a package which depends on python-environment.el
  • package users --- users of the package written by the package authors.

I think it is ideal if package users have no need for caring what python-environment.el does --- or even knowing it is installed. Package authors just let package users know that they need a Python command called virtualenv. Remember that package author could write a package that is useful non-Python programmers. Then sometimes it is hard to install some Python packages (e.g., you need Python header file for C extension). In that case, package author could just tell package users that "if you get error XXX then run sudo apt-get install python-YYY." (You might think that "then why not let people install python packages by themselvs?" But If this python library YYY is one of ten dependencies of the Emacs Lisp package, then it still makes sense to use python-environment.el to automate most of the installation). In this case, you need --system-site-packages. Also, pip install sometimes requires building C extension. If you have a package that is already build for your OS, using pip install is just waste of energy.

Besides, I don't see reason why --system-site-packages should not be default for app installation. For sure it is bad idea for development but the main purpose of python-environment.el is not development. You could write a package for Python development but in that case, you just have to override the virtualenv command. python-environment.el is aware of that and has API for that.

@tkf

This comment has been minimized.

Show comment
Hide comment
@tkf

tkf Mar 19, 2014

Owner

Closing it since I think it is not a problem.

I am open for discussion and if you have a convincing argument I may change the default in the future.

Owner

tkf commented Mar 19, 2014

Closing it since I think it is not a problem.

I am open for discussion and if you have a convincing argument I may change the default in the future.

@tkf tkf closed this Mar 19, 2014

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