Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

from packaging import version as pack_version ImportError: No module named packaging

855 views
Skip to first unread message

David Gabriel

unread,
Oct 27, 2017, 9:57:02 AM10/27/17
to
Dears,

I am running a python code that generates for me this error :

from packaging import version as pack_version
ImportError: No module named packaging

I googled it and I have found so many suggestions regarding updating 'pip'
and installing python-setuptools but all of these did not fix this issue.

Do you have any idea how can I solve this problem.
Thanks in advance.

Cameron Simpson

unread,
Oct 27, 2017, 7:08:30 PM10/27/17
to
On 27Oct2017 15:56, David Gabriel <david...@gmail.com> wrote:
>I am running a python code that generates for me this error :
>
>from packaging import version as pack_version
>ImportError: No module named packaging
>
>I googled it and I have found so many suggestions regarding updating 'pip'
>and installing python-setuptools but all of these did not fix this issue.

You need to fetch the "packaging" module. That is what pip is for, eg:

pip install --user packaging

The --user is to install it in your "personal" python library space.

Cheers,
Cameron Simpson <c...@cskk.id.au> (formerly c...@zip.com.au)

Lutz Horn

unread,
Oct 28, 2017, 2:31:39 AM10/28/17
to
On Fri, Oct 27, 2017 at 03:56:39PM +0200, David Gabriel wrote:
> from packaging import version as pack_version
> ImportError: No module named packaging
>
> I googled it and I have found so many suggestions regarding updating
> 'pip' and installing python-setuptools but all of these did not fix
> this issue.

So many questions:

* What is your Python version?
* Do you use virtualenv?
* How?
* Did you install packaging in this virtualenv?

Just one example of making this work:

$ mkdir /tmp/pack
$ cd /tmp/pack
$ virtualenv -p $(which python3.5) .
Running virtualenv with interpreter /usr/bin/python3.5
Using base prefix '/usr'
New python executable in /tmp/pack/bin/python3.5
Also creating executable in /tmp/pack/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.
$ source bin/activate
$ pip3 install packaging
Collecting packaging
Using cached packaging-16.8-py2.py3-none-any.whl
Collecting six (from packaging)
Using cached six-1.11.0-py2.py3-none-any.whl
Collecting pyparsing (from packaging)
Using cached pyparsing-2.2.0-py2.py3-none-any.whl
Installing collected packages: six, pyparsing, packaging
Successfully installed packaging-16.8 pyparsing-2.2.0 six-1.11.0
$ python3.5
Python 3.5.2 (default, Sep 14 2017, 22:51:06)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more
information.

David Gabriel

unread,
Oct 28, 2017, 8:31:19 AM10/28/17
to
Thanks so Lutz much for your reply.
I am using python2.7 and I am running this code in an Openstack instance.
I will apply your recommandation and let you know about the result ...

Kind regards.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

David Gabriel

unread,
Oct 28, 2017, 8:38:55 AM10/28/17
to
I forget to precise that I am using pycharm.
And this issue is reproducible also using command line to run the code.

Best regards

David Gabriel

unread,
Oct 30, 2017, 5:48:46 AM10/30/17
to
Dears,

When I run this command I got this error message:

ubuntu@orchestrateur:/tmp/pack$ virtualenv -p $(which python3.5) .
Running virtualenv with interpreter /usr/local/sbin/.
Traceback (most recent call last):
File "/usr/bin/virtualenv", line 3, in <module>
virtualenv.main()
File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 784, in main
popen = subprocess.Popen([interpreter, file] + sys.argv[1:], env=env)
File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
raise child_exception
OSError: [Errno 13] Permission denied


This error is also reproducible using sudo.
Please advise how to fix it.

Thanks in advance.
Best regards

Peter Otten

unread,
Oct 30, 2017, 6:15:15 AM10/30/17
to
David Gabriel wrote:

> Dears,
>
> When I run this command I got this error message:
>
> ubuntu@orchestrateur:/tmp/pack$ virtualenv -p $(which python3.5) .
> Running virtualenv with interpreter /usr/local/sbin/.
> Traceback (most recent call last):
> File "/usr/bin/virtualenv", line 3, in <module>
> virtualenv.main()
> File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 784, in main
> popen = subprocess.Popen([interpreter, file] + sys.argv[1:], env=env)
> File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
> errread, errwrite)
> File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
> raise child_exception
> OSError: [Errno 13] Permission denied
>
>
> This error is also reproducible using sudo.

When `which` does not find python3.5 your virtualenv invocation is
effectively

$ virtualenv -p .

It should be clear that the current directory is usually not a python
interpreter ;)

> Please advise how to fix it.

Provide the path to an actually existing interpreter. If you insist on
which-craft test the command first:

$ which python3.3
$ which python3.4
/usr/bin/python3.4

So on my system $(which python3.4) might work while $(which python3.3) will
not.

Cameron Simpson

unread,
Oct 30, 2017, 5:17:11 PM10/30/17
to
On 30Oct2017 10:48, David Gabriel <david...@gmail.com> wrote:
>When I run this command I got this error message:
>
>ubuntu@orchestrateur:/tmp/pack$ virtualenv -p $(which python3.5) .
[...]
>OSError: [Errno 13] Permission denied

Peter has explained this failure. Note that in the shell you can show command
execution, which is very helpful for figuring out this kind of thing:

set -x
virtualenv -p $(which python3.5) .
set +x

which would show you the actual virtualenv command invoked. In particular, it
would be apparent (if Peter's suggestion is correct) that the result of "which
python3.5" was empty, leading to an invalid "virtualenv" incantation.

However, I write about something else:

>This error is also reproducible using sudo.

I've seen this before. NEVER EVER do this! If something fails, DO NOT reach for
"sudo" to "fix" the problem. Usually things fail because of mistaken use (such
as your example) or because of some system policy forbidding the action.

In both cases the correct process is to understand why the failure occurred,
NOT to try to run the action in some special privileged mode to avoid the
check.

Please try not to reach for "sudo" by reflex. It _will_ get you into trouble
one day, either by doing unintended damage to your stuff or by raising the ire
of some sysadmin when you try it on some system that is their responsibility.

Thank you,
0 new messages