Re: [Distutils] Code for inserting paths into system configuration?

[Nick Coghlan]

On 14 September 2016 at 14:13, Nick Coghlan  wrote:
> On 14 September 2016 at 07:00, Glyph Lefkowitz  
> wrote:
>> On Sep 13, 2016, at 12:58 PM, Matthew Brett  wrote:
>>> I was reflecting on the detail of putting pip user bin directories on
>>> the user's path, and was then thinking of making a tiny pip package
>>> like this:
>>>
>>> pip install pip_user_config
>>> python -m pip_user_config
>>>
>>> where the latter would cleverly insert the user bin directory into the
>>> user's configuration.
>>>
>>> Does anyone know of any code to do something like that?
>>
>> This is shell- and platform-specific.  This would be a great idea!  But it 
>> would be a challenging integration project.
>
> I know the Anaconda installer (the Continuum Analytics one) does this
> (since I've reported a bug against it for messing up user level access
> to the system SQLite installation)

Thinking about that a bit more, I realised I was misremembering - the
bug was in the way "conda env" activation scripts worked, not in the
initial installation of Anaconda.

So those activation scripts and the equivalent ones for virtualenv and
venv are worth a look for understanding how to configure a currently
active shell session (which is shell dependent), while venv management
tools like vex and pew show how to launch a new subshell with a
reconfigured environment (which is easier to make shell independent
and portable across platforms).

What we don't currently have is anything which makes it easy to set up
a shell session where you're still using the system Python, but "pip
install" is targeting your user site-packages directory (regardless of
the system-wide default behaviour - this is the default on Debian &
Ubuntu for example, but not yet the default on Fedora et al), and you
can run scripts from "~/.local/bin" (this is the default on Fedora,
but not on Debian and Ubuntu, and not necessarily on Fedora
derivatives either)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Code for inserting paths into system configuration?

[Nick Coghlan]

On 14 September 2016 at 07:00, Glyph Lefkowitz  wrote:
> On Sep 13, 2016, at 12:58 PM, Matthew Brett  wrote:
>> I was reflecting on the detail of putting pip user bin directories on
>> the user's path, and was then thinking of making a tiny pip package
>> like this:
>>
>> pip install pip_user_config
>> python -m pip_user_config
>>
>> where the latter would cleverly insert the user bin directory into the
>> user's configuration.
>>
>> Does anyone know of any code to do something like that?
>
> This is shell- and platform-specific.  This would be a great idea!  But it 
> would be a challenging integration project.

I know the Anaconda installer (the Continuum Analytics one) does this
(since I've reported a bug against it for messing up user level access
to the system SQLite installation), but I don't know if the code for
that is publicly available anywhere (conda itself is open source, but
I'm not sure about the build scripts for their installers).

That said, as far as I know, just covering the discrepancy on Debian
and Ubuntu between "the system pip is patched to use --user by
default" and "~/.local/bin is not on PATH by default when using the
default shell" would cover most of the cases where this comes up.

Even short of automating the config change though, there could be
significant value in having a "check_install_config" utility that you
ran as:

pip install [--user] check_install_config
python -m check_install_config

and answered some essential fault diagnosis questions like:

- which Python version is being used?
- is there an active virtual environment?
- is it a venv environment or a virtualenv one?
- where will package installations go by default?
- where will they go with --user specified?
- where will script installations go in those two cases?
- are both of the binary install directories on the user's executable path?

Cheers,
NIck.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Matthias Bussonnier]

On Tue, Sep 13, 2016 at 3:55 PM, Donald Stufft  wrote:

> Perhaps a better idea would be to add some smarts to the REPL (but not to 
> Python itself) that would detect something like:
>
 pip install
>
> And print a better error message that gives a better indication about what’s 
> gone wrong besides a SyntaxError?

I've that for IPython:

https://pypi.python.org/pypi/pip_magic

It need to be loaded explicitly, but I'm[1] considering making it
enabled by default.

We're more and more encountering users that are confused with
installing form within the shell; More and more users are in a Python
REPL[2] long before even knowing what a shell command line is and how
to get one. Worse they can choose environment in a dropdown, so having
to tell them they need to activate the env to install things make no
sens for them.

I think a 'pip install', or whatever else that could hook into the
thing to install package (like something that conda could set to
theirown thing) would be great. A message like "You might need to
restart your Python interpreter for changes to be taken into account"
seem enough to C.Y.A and would get us 90% there.

-- 
M

[1] I think other dev agree with me.
[2] in a notebook most of the time
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Steve Dower]

On 13Sep2016 1559, Matthew Brett wrote:

Perhaps a better idea would be to add some smarts to the REPL (but not to 
Python itself) that would detect something like:


pip install


And print a better error message that gives a better indication about what’s 
gone wrong besides a SyntaxError?


I was thinking the same thing.  If it could also catch accidental


python3 -m pip install


commands, that would be even better.


I feel like these would deserve text adventure style errors:

>>> pip install spam
I don't see a pip here

>>> python
You're already running a Python!

>>> pip uninstall eggs
You ask nicely, but pip refuses to uninstall from inside this shell.

Cheers,
Steve
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Steve Dower]

On 13Sep2016 1555, Donald Stufft wrote:



On Sep 13, 2016, at 6:41 PM, Steve Dower  wrote:

I think it's one of these things where we should suck it up and let the 90% 
case work fine, then display a big fat warning if anything weird may have 
happened and let users sort it out themselves.



I am unsure. One of the really egregious and hard to debug weirdness is going 
to be something like:



import foo.bar  # foo, and foo.bar are in sys.modules
pip.install(“thing”)  # This implicitly upgrades foo
import foo.widget  # the old foo is in sys.modules, but the new foo.widget.




Except my version of this goes more like:

>>> import foo.bar  # foo, and foo.bar are in sys.modules
>>> pip.install("thing")  # This implicitly upgrades foo
WARNING: Packages were updated. You need to restart Python now.
>>> import foo.widget  # because I happily ignore messages starting 
with WARNING


Doesn't matter to me whether it's "safe" to keep going or not - if any 
files are overwritten at all then show the warning. (This is exactly the 
argument I was expecting when I said "those who want it to be perfect in 
every scenario" ;) )


Cheers,
Steve

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Matthew Brett]

Hi,

On Tue, Sep 13, 2016 at 3:55 PM, Donald Stufft  wrote:
>
>> On Sep 13, 2016, at 6:41 PM, Steve Dower  wrote:
>>
>> I think it's one of these things where we should suck it up and let the 90% 
>> case work fine, then display a big fat warning if anything weird may have 
>> happened and let users sort it out themselves.
>
>
> I am unsure. One of the really egregious and hard to debug weirdness is going 
> to be something like:
>
>
 import foo.bar  # foo, and foo.bar are in sys.modules
 pip.install(“thing”)  # This implicitly upgrades foo
 import foo.widget  # the old foo is in sys.modules, but the new foo.widget.
>
> The 90% case works when it’s *only* pure python and there’s no 
> upgrading/downgrading involved, however you can’t control whether there are 
> going to be upgrades/downgrades or not when dependencies are in play because 
> of ==, >=, >, <, <=, etc.
>
> Another problem, particularly on Windows, is going to be stuff like:
>
 import someclibrary
 pip.install(“thing”)  # Implicitly upgrades someclibrary
>
> In this case, this would explode because Python will have the 
> someclibrary.dll locked and the upgrade will attempt to remove it.
>
> My fears here are that people are going to get really confused when they make 
> state modifications to their Python environment and they don’t see those 
> modifications reflected (because of sys.modules caching or what have you). 
> You can possibly get around that with reload(), but we already know the 
> problems that reload() has. Of course, that doesn’t stop Python from offering 
> reload(), but I think the difference is that reload() is targeted towards 
> people with weird edge cases who can understand the caveats while the 
> hypothetical ``pip.install()`` is targeted towards people who are beginners 
> who are still having problems figuring out the difference between the REPL 
> and their shell, much less the vagaries of Python’s global state and 
> attempting to modify that in a now running Python program.
>
> Perhaps a better idea would be to add some smarts to the REPL (but not to 
> Python itself) that would detect something like:
>
 pip install
>
> And print a better error message that gives a better indication about what’s 
> gone wrong besides a SyntaxError?

I was thinking the same thing.  If it could also catch accidental

>>> python3 -m pip install

commands, that would be even better.

Cheers,

Matthew
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Donald Stufft]

> On Sep 13, 2016, at 6:41 PM, Steve Dower  wrote:
> 
> I think it's one of these things where we should suck it up and let the 90% 
> case work fine, then display a big fat warning if anything weird may have 
> happened and let users sort it out themselves.


I am unsure. One of the really egregious and hard to debug weirdness is going 
to be something like:


>>> import foo.bar  # foo, and foo.bar are in sys.modules
>>> pip.install(“thing”)  # This implicitly upgrades foo
>>> import foo.widget  # the old foo is in sys.modules, but the new foo.widget.

The 90% case works when it’s *only* pure python and there’s no 
upgrading/downgrading involved, however you can’t control whether there are 
going to be upgrades/downgrades or not when dependencies are in play because of 
==, >=, >, <, <=, etc.

Another problem, particularly on Windows, is going to be stuff like:

>>> import someclibrary
>>> pip.install(“thing”)  # Implicitly upgrades someclibrary

In this case, this would explode because Python will have the someclibrary.dll 
locked and the upgrade will attempt to remove it.

My fears here are that people are going to get really confused when they make 
state modifications to their Python environment and they don’t see those 
modifications reflected (because of sys.modules caching or what have you). You 
can possibly get around that with reload(), but we already know the problems 
that reload() has. Of course, that doesn’t stop Python from offering reload(), 
but I think the difference is that reload() is targeted towards people with 
weird edge cases who can understand the caveats while the hypothetical 
``pip.install()`` is targeted towards people who are beginners who are still 
having problems figuring out the difference between the REPL and their shell, 
much less the vagaries of Python’s global state and attempting to modify that 
in a now running Python program.

Perhaps a better idea would be to add some smarts to the REPL (but not to 
Python itself) that would detect something like:

>>> pip install

And print a better error message that gives a better indication about what’s 
gone wrong besides a SyntaxError?


—
Donald Stufft



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Jeremy Stanley]

On 2016-09-13 23:00:25 +0100 (+0100), Paul Moore wrote:
[...]
> And things get significantly worse if we allow upgrades from the
> Python prompt rather than just installs (e.g., if you have already
> imported something from the old version and then upgrade).
[...]

If you need it, and of course only if your software is actually
written to handle it (contextually), there is a function to handle
that:

https://docs.python.org/2/library/functions.html#reload
https://docs.python.org/3/library/importlib.html#importlib.reload

I've used it in some very specific situations where you need to
change out parts of a running daemon without restarting the process,
but you really need a lot of extra care to get out of contexts
utilizing the modules being reloaded if you want the replacements to
actually be used.
-- 
Jeremy Stanley
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Steve Dower]

On 13Sep2016 1500, Paul Moore wrote:

On 13 September 2016 at 21:12, Thomas Kluyver  wrote:

One thing I'd quite like to see Python grow is a standard function to
install packages from inside Python.


That's not too hard in principle - pip.main(['install', package]) is
basically all you'd need (modulo various design details, and wrapping
it in a nice user friendly function). The bigger problems are:

1. pip is an independent module (albeit shipped with Python) and it's
not clear to what extent Python would want a builtin function that
depends on a non-stdlib module. But that's not a technical issue.
2. Python's module system isn't really designed around installing new
modules while a process is running. There's caching involved, so the
effects can be unpredictable. It's difficult to know whether the
benefits (avoiding confused users who tried to install from a Python
prompt) would outweigh the costs (confused users having installed a
module but not being able to see it because the module system didn't
notice things had changed).

I'm not honestly sure how big the "installing while a process is
running" issue would be - I did a few simple experiments and couldn't
immediately trigger weirdness, but I believe it can happen. And things
get significantly worse if we allow upgrades from the Python prompt
rather than just installs (e.g., if you have already imported
something from the old version and then upgrade).

Overall, it'd probably be a nice thing to have, but it's nowhere near
as simple as it seems at first glance.
Paul


I think it's one of these things where we should suck it up and let the 
90% case work fine, then display a big fat warning if anything weird may 
have happened and let users sort it out themselves.


A simple builtin that tries to run "sys.executable -m pip {args}" in a 
subprocess and displays "success", "success but you should probably 
restart Python now", "failed because you don't have pip", "failed and 
have all the output" is going to make lots of people happy, even if it 
upsets those who want it to be perfect in every scenario.


Cheers,
Steve

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Leonardo Rochael Almeida]

On 13 September 2016 at 19:00, Paul Moore  wrote:

> [...]
>
> I'm not honestly sure how big the "installing while a process is
> running" issue would be - I did a few simple experiments and couldn't
> immediately trigger weirdness, but I believe it can happen. And things
> get significantly worse if we allow upgrades from the Python prompt
> rather than just installs (e.g., if you have already imported
> something from the old version and then upgrade).
>

The only weirdness on install I can imagine would happen is if the
installation creates `.pth` files, as those wouldn't be re-read by the
currently running Python.

The only package I remember having these was PIL, which can't be installed
by pip anyway. Pillow, the PIL fork, doesn't use .pth files.

(easy_install creates and manages .pth files, but if you're using
setuptools APIs to install packages from inside a running process then 1.
you already have a system to automatically make the packages available in
your namespace and 2. you know, or should know, what you're getting into).

Overall, it'd probably be a nice thing to have, but it's nowhere near
> as simple as it seems at first glance.
> Paul


Considering that installing a package and importing a package are two very
different things, I don't see why we couldn't handle the simple case of
installing the package for the first time with a nice API. Just document
the usual caveat emptors.

Cheers,

Leo
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Paul Moore]

On 13 September 2016 at 21:12, Thomas Kluyver  wrote:
> One thing I'd quite like to see Python grow is a standard function to
> install packages from inside Python.

That's not too hard in principle - pip.main(['install', package]) is
basically all you'd need (modulo various design details, and wrapping
it in a nice user friendly function). The bigger problems are:

1. pip is an independent module (albeit shipped with Python) and it's
not clear to what extent Python would want a builtin function that
depends on a non-stdlib module. But that's not a technical issue.
2. Python's module system isn't really designed around installing new
modules while a process is running. There's caching involved, so the
effects can be unpredictable. It's difficult to know whether the
benefits (avoiding confused users who tried to install from a Python
prompt) would outweigh the costs (confused users having installed a
module but not being able to see it because the module system didn't
notice things had changed).

I'm not honestly sure how big the "installing while a process is
running" issue would be - I did a few simple experiments and couldn't
immediately trigger weirdness, but I believe it can happen. And things
get significantly worse if we allow upgrades from the Python prompt
rather than just installs (e.g., if you have already imported
something from the old version and then upgrade).

Overall, it'd probably be a nice thing to have, but it's nowhere near
as simple as it seems at first glance.
Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Chris Barker]

>
> I think Ryan may have typed that command at a Python prompt rather than
>> a system command prompt. Unfortunately the distinction often isn't clear
>> in examples, because the experienced developers writing the instructions
>> are used to guessing which commands are Python and which are system
>> commands.
>>
>
indeed -- not a rare error for newbies.


> One thing I'd quite like to see Python grow is a standard function to
>> install packages from inside Python.
>
>
indeed:

import pip

pip.install('package_name')

would make lots of sense, except:

1) It is going to have to be a different command than the shell command, so
the above confusion would still be an issue.

2) are there any technicals reasons this would fail -- i.e. sys.path would
have to be re-calculated at least -- any other re-initializaton that would
have to be done?

3) permissions could be an issue, you don't necessarily want python to be
running with the permissions to write to it's install dir

In short -- I like the idea, but I'm not sure it'll really help the newbie
confusion.

-CHB








> In R, the install.packages()
>> function is the default way to get third party packages, and I think
>> staying in one interactive prompt does make things easier for new users
>> to understand.
>>
>
> Ah, I suspect you're right.
>
> I have considered adding a "Python x.y Shell" start menu item that would
> configure PATH properly for commands like "python" and "pip".
> Instinctively, it seems this would be more useful than a direct shortcut to
> the executable, but at the same time I don't want to start competing with
> all the other app-specific shells out there.
>
> Cheers,
> Steve
>
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Buoldout2 e setup.py: install_requires ignored

[Jim Fulton]

Gaaa, I should have stayed mum.  Missed referring to the develop egg
too, as Leonardo pointed out.

Thanks.

Jim

On Tue, Sep 13, 2016 at 5:18 PM, Fred Drake  wrote:
> On Tue, Sep 13, 2016 at 4:44 PM, Jim Fulton  wrote:
>> You're missing:
>>
>>develop .
>>
>> to have buildout create and include a develop egg using the current
>> directory with it's dependencies.
>
> Ahem.
>
> develop = .
>
>
>
>   -Fred
>
> --
> Fred L. Drake, Jr.
> "A storm broke loose in my mind."  --Albert Einstein



-- 
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Code for inserting paths into system configuration?

[Glyph Lefkowitz]

> On Sep 13, 2016, at 12:58 PM, Matthew Brett  wrote:
> 
> Hi,
> 
> I was reflecting on the detail of putting pip user bin directories on
> the user's path, and was then thinking of making a tiny pip package
> like this:
> 
> pip install pip_user_config
> python -m pip_user_config
> 
> where the latter would cleverly insert the user bin directory into the
> user's configuration.
> 
> Does anyone know of any code to do something like that?

This is shell- and platform-specific.  This would be a great idea!  But it 
would be a challenging integration project.

-glyph


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Buoldout2 e setup.py: install_requires ignored

[Jim Fulton]

On Tue, Sep 13, 2016 at 4:07 PM, Alessandro Dentella  wrote:
> Hi,
>
>
> I just migrated from buildout 1.7 to buildout 2.5. In this migration I
> stopped using a recipe that created a virtualenv as a part of
> buildout and I now use an external (basic) virtualenv to calll
> bootrap, so I can't compare the two configuration in a strict way.
>
> My problem is that now it seems that install_requires declared in
> setup.py are simply ignored, while all packages declared in the eggs
> directory are used/installed along with all the packages they depends
> on.
>
> I can't find what's wrong with my configuration, I report below a
> minimal setup that shows the problem.
>
> thanks in advance for any hints
>
> sandro
> *:-)
>
> sandro@bluff:/tmp/new$ cat buildout.cfg
> [buildout]
> parts = django
> eggs = django
>ipython
>django_extensions
> project-name = mytest

You're missing:

   develop .

to have buildout create and include a develop egg using the current
directory with it's dependencies.

Jim

-- 
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Buoldout2 e setup.py: install_requires ignored

[Leonardo Rochael Almeida]

Hi Sandro,

I don't know what your previous setup did, but in your current setup, your
`buildout.cfg` is not configured to take your `setup.py` into account in
any way.

In the `eggs` setting, only `django`, `ipython` and `django-settings` are
mentioned. To take your `setup.py` into account it should mention your
package by name as well (by the way, please consider using a name that
doesn't contain spaces, instead of "example with buildout2".

E.g. assuming you rename your package to "mypackage" in `setup.py`, and
this `setup.py` is in the root of your buildout, the following
`buildout.cfg` should install your package and its `install_requires`:

[buildout]
parts = django
develop = .
eggs =
   mypackage
   django
   ipython
   django_extensions
project-name = mytest

[django]
recipe = djangorecipe
settings = settings
eggs = ${buildout:eggs}



On 13 September 2016 at 17:07, Alessandro Dentella  wrote:

> Hi,
>
>
> I just migrated from buildout 1.7 to buildout 2.5. In this migration I
> stopped using a recipe that created a virtualenv as a part of
> buildout and I now use an external (basic) virtualenv to calll
> bootrap, so I can't compare the two configuration in a strict way.
>
> My problem is that now it seems that install_requires declared in
> setup.py are simply ignored, while all packages declared in the eggs
> directory are used/installed along with all the packages they depends
> on.
>
> I can't find what's wrong with my configuration, I report below a
> minimal setup that shows the problem.
>
> thanks in advance for any hints
>
> sandro
> *:-)
>
> sandro@bluff:/tmp/new$ cat buildout.cfg
> [buildout]
> parts = django
> eggs = django
>ipython
>django_extensions
> project-name = mytest
>
> [django]
> recipe = djangorecipe
> settings = settings
> eggs = ${buildout:eggs}
>
> 
> sandro@bluff:/tmp/new$ cat setup.py
> from setuptools import setup, find_packages
>
> setup(
> name = "example with buildout2",
> version = "0.1",
> author = "Sandro",
> author_email = "san...@e-den.it",
> description = ("Sperem ghe la vaga ben"),
> license = "BSD",
> url = "http://hg.trepalchi.it/;,
> #packages=['an_example_pypi_project', 'tests'],
> long_description="Bla bla",
> classifiers=[
> "Development Status :: 3 - Alpha",
> "Topic :: Utilities",
> "License :: OSI Approved :: BSD License",
> ],
> install_requires=[
> 'pyquery',
> ]
> )
>
>
> The steps I do::
>
>   mkvirtualenv -p /usr/bin/python3 base3
>   /home/sandro/.virtualenvs/base3/bin/python3 bootstrap.py
>   ./bin/buildout
>
> And I obtain bin/django where pyquery **is missing**
>
> $ cat bin/django
> #!/home/sandro/.virtualenvs/base3/bin/python3
>
> import sys
> sys.path[0:0] = [
>   '/home/sandro/.buildout/eggs/Django-1.10.1-py3.5.egg',
>   '/home/sandro/.buildout/eggs/ipython-5.0.0-py3.5.egg',
>   '/home/sandro/.buildout/eggs/djangorecipe-2.2.1-py3.5.egg',
>   '/home/sandro/.buildout/eggs/zc.recipe.egg-2.0.3-py3.5.egg',
>   '/home/sandro/.buildout/eggs/zc.buildout-2.5.3-py3.5.egg',
>   '/home/sandro/.buildout/eggs/pexpect-4.2.1-py3.5.egg',
>   '/home/sandro/.buildout/eggs/Pygments-2.1.3-py3.5.egg',
>   '/home/sandro/.buildout/eggs/prompt_toolkit-1.0.7-py3.5.egg',
>   '/home/sandro/.buildout/eggs/traitlets-4.2.2-py3.5.egg',
>   '/home/sandro/.buildout/eggs/simplegeneric-0.8.1-py3.5.egg',
>   '/home/sandro/.buildout/eggs/pickleshare-0.7.4-py3.5.egg',
>   '/home/sandro/.buildout/eggs/decorator-4.0.10-py3.5.egg',
>   '/home/sandro/.buildout/eggs/setuptools-27.1.2-py3.5.egg',
>   '/home/sandro/.buildout/eggs/ptyprocess-0.5.1-py3.5.egg',
>   '/home/sandro/.buildout/eggs/wcwidth-0.1.7-py3.5.egg',
>   '/home/sandro/.buildout/eggs/six-1.10.0-py3.5.egg',
>   '/home/sandro/.buildout/eggs/ipython_genutils-0.1.0-py3.5.egg',
>   '/tmp/new',
>   ]
>
> import djangorecipe.binscripts
>
> if __name__ == '__main__':
> sys.exit(djangorecipe.binscripts.manage('project.settings'))
>
>
>
> --
> Sandro Dentella  *:-)
> http://trepalchi.itIl portale degli artisti
>
> http://www.reteisi.org Soluzioni libere per le scuole
> http://sqlkit.argolinux.orgSQLkit home page -
> PyGTK/python/sqlalchemy
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Buoldout2 e setup.py: install_requires ignored

[Alessandro Dentella]

Hi,


I just migrated from buildout 1.7 to buildout 2.5. In this migration I
stopped using a recipe that created a virtualenv as a part of
buildout and I now use an external (basic) virtualenv to calll
bootrap, so I can't compare the two configuration in a strict way.

My problem is that now it seems that install_requires declared in
setup.py are simply ignored, while all packages declared in the eggs
directory are used/installed along with all the packages they depends
on.

I can't find what's wrong with my configuration, I report below a
minimal setup that shows the problem.

thanks in advance for any hints

sandro
*:-)

sandro@bluff:/tmp/new$ cat buildout.cfg
[buildout]
parts = django
eggs = django
   ipython
   django_extensions
project-name = mytest

[django]
recipe = djangorecipe
settings = settings
eggs = ${buildout:eggs}


sandro@bluff:/tmp/new$ cat setup.py
from setuptools import setup, find_packages

setup(
name = "example with buildout2",
version = "0.1",
author = "Sandro",
author_email = "san...@e-den.it",
description = ("Sperem ghe la vaga ben"),
license = "BSD",
url = "http://hg.trepalchi.it/;,
#packages=['an_example_pypi_project', 'tests'],
long_description="Bla bla",
classifiers=[
"Development Status :: 3 - Alpha",
"Topic :: Utilities",
"License :: OSI Approved :: BSD License",
],
install_requires=[
'pyquery',
]
)


The steps I do::

  mkvirtualenv -p /usr/bin/python3 base3
  /home/sandro/.virtualenvs/base3/bin/python3 bootstrap.py
  ./bin/buildout

And I obtain bin/django where pyquery **is missing**

$ cat bin/django
#!/home/sandro/.virtualenvs/base3/bin/python3

import sys
sys.path[0:0] = [
  '/home/sandro/.buildout/eggs/Django-1.10.1-py3.5.egg',
  '/home/sandro/.buildout/eggs/ipython-5.0.0-py3.5.egg',
  '/home/sandro/.buildout/eggs/djangorecipe-2.2.1-py3.5.egg',
  '/home/sandro/.buildout/eggs/zc.recipe.egg-2.0.3-py3.5.egg',
  '/home/sandro/.buildout/eggs/zc.buildout-2.5.3-py3.5.egg',
  '/home/sandro/.buildout/eggs/pexpect-4.2.1-py3.5.egg',
  '/home/sandro/.buildout/eggs/Pygments-2.1.3-py3.5.egg',
  '/home/sandro/.buildout/eggs/prompt_toolkit-1.0.7-py3.5.egg',
  '/home/sandro/.buildout/eggs/traitlets-4.2.2-py3.5.egg',
  '/home/sandro/.buildout/eggs/simplegeneric-0.8.1-py3.5.egg',
  '/home/sandro/.buildout/eggs/pickleshare-0.7.4-py3.5.egg',
  '/home/sandro/.buildout/eggs/decorator-4.0.10-py3.5.egg',
  '/home/sandro/.buildout/eggs/setuptools-27.1.2-py3.5.egg',
  '/home/sandro/.buildout/eggs/ptyprocess-0.5.1-py3.5.egg',
  '/home/sandro/.buildout/eggs/wcwidth-0.1.7-py3.5.egg',
  '/home/sandro/.buildout/eggs/six-1.10.0-py3.5.egg',
  '/home/sandro/.buildout/eggs/ipython_genutils-0.1.0-py3.5.egg',
  '/tmp/new',
  ]

import djangorecipe.binscripts

if __name__ == '__main__':
sys.exit(djangorecipe.binscripts.manage('project.settings'))



--
Sandro Dentella  *:-)
http://trepalchi.itIl portale degli artisti

http://www.reteisi.org Soluzioni libere per le scuole
http://sqlkit.argolinux.orgSQLkit home page - PyGTK/python/sqlalchemy
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Steve Dower]

On 13Sep2016 1312, Thomas Kluyver wrote:

On Tue, Sep 13, 2016, at 08:39 PM, Steve Dower wrote:

It would help if you could post the full error output (sanitizing
paths if needed). But you may just need to upgrade pip (python -m
install -U pip).


I think Ryan may have typed that command at a Python prompt rather than
a system command prompt. Unfortunately the distinction often isn't clear
in examples, because the experienced developers writing the instructions
are used to guessing which commands are Python and which are system
commands.

One thing I'd quite like to see Python grow is a standard function to
install packages from inside Python. In R, the install.packages()
function is the default way to get third party packages, and I think
staying in one interactive prompt does make things easier for new users
to understand.


Ah, I suspect you're right.

I have considered adding a "Python x.y Shell" start menu item that would 
configure PATH properly for commands like "python" and "pip". 
Instinctively, it seems this would be more useful than a direct shortcut 
to the executable, but at the same time I don't want to start competing 
with all the other app-specific shells out there.


Cheers,
Steve


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Thomas Kluyver]

On Tue, Sep 13, 2016, at 08:39 PM, Steve Dower wrote:
> It would help if you could post the full error output (sanitizing
> paths if needed). But you may just need to upgrade pip (python -m
> install -U pip).

I think Ryan may have typed that command at a Python prompt rather than
a system command prompt. Unfortunately the distinction often isn't
clear in examples, because the experienced developers writing the
instructions are used to guessing which commands are Python and which
are system commands.

One thing I'd quite like to see Python grow is a standard function to
install packages from inside Python. In R, the install.packages()
function is the default way to get third party packages, and I think
staying in one interactive prompt does make things easier for new users
to understand.

Thomas
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Steve Dower]

It would help if you could post the full error output (sanitizing paths if 
needed). But you may just need to upgrade pip (python -m install -U pip).

Knowing exactly where the syntax error is coming from will help us figure out 
which package has the problem. There are at least three involved here.

Cheers,
Steve

Top-posted from my Windows Phone

-Original Message-
From: "Mills, Ryan" 
Sent: ‎9/‎13/‎2016 9:56
To: "distutils-sig@python.org" 
Subject: [Distutils] Module Installation Issues

I just recently downloaded Python 3.5 and cannot seem to install any packages 
like Numpy, etc.  I have tried all the instructions on the website and keep 
getting errors:
 
For example, when I type “python –m pip install Numpy” it returns  a Syntax 
Error. I am completely new to Python so I must be missing something here – I 
haven’t altered any files since installing it the other day. Do I use the 
Python IDLE Shell? Are there other packages I need to install first?  Any help 
would be greatly appreciated.  
 
-Ryan
 
Ryan Mills
Quantitative Risk Analyst, Banking Officer

Capital Analytics & Stress Testing
2000 McKinney Avenue, Suite 700
Dallas, TX 75201
214.932.6653 direct
20.6653 internal
ryan.mi...@texascapitalbank.com



 
If you are not the addressee and have received this email in error, please 
notify me immediately. This email is confidential and may contain privileged or 
proprietary information that is unlawful for you to read, copy, distribute, 
disclose or otherwise use in any way.

 
 ___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Module Installation Issues

[Paul Moore]

On 13 September 2016 at 15:48, Mills, Ryan 
wrote:

> Do I use the Python IDLE Shell?


No, pip is a command line utility so you should go to the command prompt
and run "py -m pip install numpy" (I assume you're on Windows - on Unix
you'd need to run the appropriate python command).

Paul
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Module Installation Issues

[Mills, Ryan]

I just recently downloaded Python 3.5 and cannot seem to install any packages 
like Numpy, etc.  I have tried all the instructions on the website and keep 
getting errors:

For example, when I type "python -m pip install Numpy" it returns  a Syntax 
Error. I am completely new to Python so I must be missing something here - I 
haven't altered any files since installing it the other day. Do I use the 
Python IDLE Shell? Are there other packages I need to install first?  Any help 
would be greatly appreciated.

-Ryan

Ryan Mills
Quantitative Risk Analyst, Banking Officer

[cid:image001.jpg@01CA3228.EF8AEBA0]

Capital Analytics & Stress Testing
2000 McKinney Avenue, Suite 700
Dallas, TX 75201
214.932.6653 direct
20.6653 internal
ryan.mi...@texascapitalbank.com

[cid:image001.jpg@01CA3228.EF8AEBA0]

[TCB_horiz_Log_rgb]
[cid:image004.jpg@01D20DA2.E1988D60]


If you are not the addressee and have received this email in error, please 
notify me immediately. This email is confidential and may contain privileged or 
proprietary information that is unlawful for you to read, copy, distribute, 
disclose or otherwise use in any way.



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig