ets update to 4.3 fails

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

ets update to 4.3 fails

Michael Aye
ets-4.3.0-1.egg                                                  [installing]
    22 KB [.................................................................]
Traceback (most recent call last):
  File "/usr/local/epd/bin/enpkg", line 10, in <module>
    sys.exit(main())
  File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",
line 634, in main
    update_all(enpkg, args)
  File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",
line 245, in update_all
    install_req(enpkg, update['current']['name'], args)
  File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",
line 387, in install_req
    _perform_install()
  File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",
line 305, in _perform_install
    print "No update necessary, %r is up-to-date." % req.name
AttributeError: 'unicode' object has no attribute 'name'

This fails currently both on 64-bit MacOSX and Linux (I believe I use
the newest Redhat package).

Michael



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Michael Aye
On 2013-04-03 01:37:36 +0000, K.-Michael Aye said:

> ets-4.3.0-1.egg                                                  [installing]
>     22 KB [.................................................................]
> Traceback (most recent call last):
>   File "/usr/local/epd/bin/enpkg", line 10, in <module>
>     sys.exit(main())
>   File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",
> line 634, in main
>     update_all(enpkg, args)
>   File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",
> line 245, in update_all
>     install_req(enpkg, update['current']['name'], args)
>   File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",
> line 387, in install_req
>     _perform_install()
>   File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",
> line 305, in _perform_install
>     print "No update necessary, %r is up-to-date." % req.name
> AttributeError: 'unicode' object has no attribute 'name'
>
> This fails currently both on 64-bit MacOSX and Linux (I believe I use
> the newest Redhat package).
>
> Michael

I was incorrect, on OSX it fails at etsproxy:

etsproxy-0.1.1-1.egg                                               [removing]
  1.03 MB [.................................................................]
etsproxy-0.1.2-1.egg                                             [installing]
  1.04 MB [.................................................................]
Traceback (most recent call last):
  File
"/Library/Frameworks/Python.framework/Versions/Current/bin/enpkg", line
10, in <module>
    sys.exit(main())
  File
"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
line 634, in main
    update_all(enpkg, args)
  File
"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
line 245, in update_all
    install_req(enpkg, update['current']['name'], args)
  File
"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
line 387, in install_req
    _perform_install()
  File
"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
line 308, in _perform_install
    if mode == 'root' or e.req is None or e.req == req:
  File
"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/resolve.py",
line 89, in __eq__
    return (self.name == other.name  and
AttributeError: 'unicode' object has no attribute 'name'

BTW, why is the OSX enpkg going through the cycle
'fetching-removing-installing' for every package while the linux enpkg
is doing a bunch of removals and then a bunch of installs? Why the
difference?

Best,
Michael


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Jonathan March
Michael, what do you get from this on each platform?:
enpkg --config
enpkg enstaller

Also, on OSX, your traceback shows interaction between your 32-bit ad 64-bit installations:
/Library/Frameworks/Python.framework/Versions/Current/
/Library/Frameworks/EPD64.framework/Versions/7.3/

From your python prompt, what do you get from this?:
pprint.pprint(sys.path)

Thanks,
Jonathan

On Tue, Apr 2, 2013 at 8:42 PM, K.-Michael Aye <[hidden email]> wrote:
On 2013-04-03 01:37:36 +0000, K.-Michael Aye said:

> ets-4.3.0-1.egg                                                  [installing]
>     22 KB [.................................................................]
> Traceback (most recent call last):
>   File "/usr/local/epd/bin/enpkg", line 10, in <module>
>     sys.exit(main())
>   File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",
> line 634, in main
>     update_all(enpkg, args)
>   File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",
> line 245, in update_all
>     install_req(enpkg, update['current']['name'], args)
>   File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",
> line 387, in install_req
>     _perform_install()
>   File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",
> line 305, in _perform_install
>     print "No update necessary, %r is up-to-date." % req.name
> AttributeError: 'unicode' object has no attribute 'name'
>
> This fails currently both on 64-bit MacOSX and Linux (I believe I use
> the newest Redhat package).
>
> Michael

I was incorrect, on OSX it fails at etsproxy:

etsproxy-0.1.1-1.egg                                               [removing]
  1.03 MB [.................................................................]
etsproxy-0.1.2-1.egg                                             [installing]
  1.04 MB [.................................................................]
Traceback (most recent call last):
  File
"/Library/Frameworks/Python.framework/Versions/Current/bin/enpkg", line
10, in <module>
    sys.exit(main())
  File
"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
line 634, in main
    update_all(enpkg, args)
  File
"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
line 245, in update_all
    install_req(enpkg, update['current']['name'], args)
  File
"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
line 387, in install_req
    _perform_install()
  File
"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
line 308, in _perform_install
    if mode == 'root' or e.req is None or e.req == req:
  File
"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/resolve.py",
line 89, in __eq__
    return (self.name == other.name  and
AttributeError: 'unicode' object has no attribute 'name'

BTW, why is the OSX enpkg going through the cycle
'fetching-removing-installing' for every package while the linux enpkg
is doing a bunch of removals and then a bunch of installs? Why the
difference?

Best,
Michael


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Michael Aye

On 2013-04-03 02:24:15 +0000, Jonathan March said:


Michael, what do you get from this on each platform?:

enpkg --config


OSX:

()[maye@lunatic .../Versions]$ sudo enpkg --config

Python version: 2.7

enstaller version: 4.6.0

sys.prefix: /Library/Frameworks/EPD64.framework/Versions/7.3

platform: Darwin-12.3.0-x86_64-i386-64bit

architecture: 64bit

use_webservice: True

config file: /Users/maye/.enstaller4rc

settings:

    prefix = /Library/Frameworks/EPD64.framework/Versions/7.3

    local = '/Library/Frameworks/EPD64.framework/Versions/7.3/LOCAL-REPO'

    noapp = False

    proxy = None

    IndexedRepos: (not used)

        'https://www.enthought.com/repo/epd/GPL-eggs/MacOSX/amd64/'

        'https://www.enthought.com/repo/epd/eggs/MacOSX/amd64/'

        'http://www.enthought.com/repo/pypi/eggs/MacOSX/amd64/'

You are logged in as [hidden email] (Michael Aye).

Subscription level: EPD Basic or above


enpkg enstaller

OSX:

)[maye@lunatic .../Versions]$ sudo enpkg enstaller

prefix: /Library/Frameworks/EPD64.framework/Versions/7.3

No update necessary, 'enstaller' is up-to-date.

enstaller-4.6.0-1.egg was installed on: Tue Apr  2 18:35:30 2013

(I was asked today to install a new version on both OSes)




Also, on OSX, your traceback shows interaction between your 32-bit ad 64-bit installations:

/Library/Frameworks/Python.framework/Versions/Current/

/Library/Frameworks/EPD64.framework/Versions/7.3/


The former is soft-linked to the latter on my system. Do you think that's bad?



From your python prompt, what do you get from this?:

pprint.pprint(sys.path)


In [2]: pprint.pprint(sys.path)

['',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/bin',

 '/Library/Frameworks/SQLite3.framework/Versions/3/Python/2.7',

 '/Library/Frameworks/GDAL.framework/Versions/1.9/Python/2.7/site-packages',

 '/Library/Frameworks/cairo.framework/Versions/1/Python/2.7',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/pip-1.2.1-py2.7.egg',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enaml-0.6.8-py2.7.egg',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/pandas-0.11.0.dev_9167213-py2.7-macosx-10.5-x86_64.egg',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/scikit_image-0.9dev-py2.7-macosx-10.5-x86_64.egg',

 '/usr/local/lib/python2.7/site-packages',

 '/Users/maye/Dropbox/DDocuments/BELA/software',

 '/Users/maye/Library/Python/2.7/site-packages',

 '/Users/maye/Dropbox/src/pymars',

 '/Users/maye/Dropbox/src/diviner',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python27.zip',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/plat-darwin',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/plat-mac',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/plat-mac/lib-scriptpackages',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/lib-tk',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/lib-old',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/lib-dynload',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/PIL',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages',

 '/Library/Python/2.7/site-packages',

 '/usr/local/lib/wxPython-2.9.4.0/lib/python2.7',

 '/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/IPython/extensions']



I realise now that this could be a problem, because some self-compiled files in $HOME/Library/Python/2.7/site-package do not distinguish between 32-bit and 64-bit, I guess?


Thanks for the help,


Michael




Thanks,

Jonathan


On Tue, Apr 2, 2013 at 8:42 PM, K.-Michael Aye <[hidden email]> wrote:

On 2013-04-03 01:37:36 +0000, K.-Michael Aye said:


> ets-4.3.0-1.egg                                                  [installing]

>     22 KB [.................................................................]

> Traceback (most recent call last):

>   File "/usr/local/epd/bin/enpkg", line 10, in <module>

>     sys.exit(main())

>   File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",

> line 634, in main

>     update_all(enpkg, args)

>   File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",

> line 245, in update_all

>     install_req(enpkg, update['current']['name'], args)

>   File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",

> line 387, in install_req

>     _perform_install()

>   File "/usr/local/epd/lib/python2.7/site-packages/enstaller/main.py",

> line 305, in _perform_install

>     print "No update necessary, %r is up-to-date." % req.name

> AttributeError: 'unicode' object has no attribute 'name'

>

> This fails currently both on 64-bit MacOSX and Linux (I believe I use

> the newest Redhat package).

>

> Michael


I was incorrect, on OSX it fails at etsproxy:


etsproxy-0.1.1-1.egg                                               [removing]

  1.03 MB [.................................................................]

etsproxy-0.1.2-1.egg                                             [installing]

  1.04 MB [.................................................................]

Traceback (most recent call last):

  File

"/Library/Frameworks/Python.framework/Versions/Current/bin/enpkg", line

10, in <module>

    sys.exit(main())

  File

"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",

line 634, in main

    update_all(enpkg, args)

  File

"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",

line 245, in update_all

    install_req(enpkg, update['current']['name'], args)

  File

"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",

line 387, in install_req

    _perform_install()

  File

"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",

line 308, in _perform_install

    if mode == 'root' or e.req is None or e.req == req:

  File

"/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/resolve.py",

line 89, in __eq__

    return (self.name == other.name  and

AttributeError: 'unicode' object has no attribute 'name'


BTW, why is the OSX enpkg going through the cycle

'fetching-removing-installing' for every package while the linux enpkg

is doing a bunch of removals and then a bunch of installs? Why the

difference?


Best,

Michael



_______________________________________________

Enthought-Dev mailing list

[hidden email]

https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________

Enthought-Dev mailing list

[hidden email]

https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Puneeth Chaganti
In reply to this post by Michael Aye
Hi Michael,

On Wed, Apr 3, 2013 at 7:12 AM, K.-Michael Aye <[hidden email]> wrote:
[..]
> AttributeError: 'unicode' object has no attribute 'name'

Thanks for reporting the issue, and this should be fixed, soon.  I
have sent a PR for this.  But, until then, you can just run the
--update-all command repeatedly, until all your packages are updated.

Hope that helps,
Puneeth
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Jonathan March
Michael,

1. Did Puneeth's suggestion work ok for you for getting the updates installed?

2. The fetch-remove-install cycle per package is the normal behavior. I'm surprised at what you report in Linux.

3. Your soft linking of the standard 32-bit install dir into the 64 dir is not necessarily a problem, especially since you don't have it anywhere on sys.path (e.g. from PYTHONPATH). But be aware that this can be risky, because Python's identification of modules is path-based, so if you somehow import the same module twice (once with each path), Python may import it twice separately; then stateful module-level objects would be repeated, and subtle bugs could ensue.

4. Self-compiled pure Python modules will be the same for 32- and 64-bit (indeed, for all platforms), so no problem there. But if they contain  any c extensions, you'll be in big trouble.

hth,
Jonathan




On Wed, Apr 3, 2013 at 3:29 AM, Puneeth Chaganti <[hidden email]> wrote:
Hi Michael,

On Wed, Apr 3, 2013 at 7:12 AM, K.-Michael Aye <[hidden email]> wrote:
[..]
> AttributeError: 'unicode' object has no attribute 'name'

Thanks for reporting the issue, and this should be fixed, soon.  I
have sent a PR for this.  But, until then, you can just run the
--update-all command repeatedly, until all your packages are updated.

Hope that helps,
Puneeth
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Jonathan March
Michael,

While testing this fix (not yet online), I gained a bit more insight into the fetch-remove-install sequence which you asked about. 

AFAICT, there's no OS difference. What you noticed reflects the behavior of enpkg's handling of requirements (dependencies). Basically, before installing a given package, it will fetch all that package's unsatisfied requirements; if that is successful it will remove them all, and then install them all., and finally install the originally requested package. 

So the order of operations that you see depends very much on what you're installing, and which of its requirements are already installed.

hth,
Jonathan


On Thu, Apr 4, 2013 at 1:39 PM, Jonathan March <[hidden email]> wrote:
Michael,

1. Did Puneeth's suggestion work ok for you for getting the updates installed?

2. The fetch-remove-install cycle per package is the normal behavior. I'm surprised at what you report in Linux.

3. Your soft linking of the standard 32-bit install dir into the 64 dir is not necessarily a problem, especially since you don't have it anywhere on sys.path (e.g. from PYTHONPATH). But be aware that this can be risky, because Python's identification of modules is path-based, so if you somehow import the same module twice (once with each path), Python may import it twice separately; then stateful module-level objects would be repeated, and subtle bugs could ensue.

4. Self-compiled pure Python modules will be the same for 32- and 64-bit (indeed, for all platforms), so no problem there. But if they contain  any c extensions, you'll be in big trouble.

hth,
Jonathan




On Wed, Apr 3, 2013 at 3:29 AM, Puneeth Chaganti <[hidden email]> wrote:
Hi Michael,

On Wed, Apr 3, 2013 at 7:12 AM, K.-Michael Aye <[hidden email]> wrote:
[..]
> AttributeError: 'unicode' object has no attribute 'name'

Thanks for reporting the issue, and this should be fixed, soon.  I
have sent a PR for this.  But, until then, you can just run the
--update-all command repeatedly, until all your packages are updated.

Hope that helps,
Puneeth
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Michael Aye
On 2013-04-04 21:53:45 +0000, Jonathan March said:

> Michael,
>
> While testing this fix (not yet online), I gained a bit more insight
> into the fetch-remove-install sequence which you asked about. 
>
> AFAICT, there's no OS difference. What you noticed reflects the
> behavior of enpkg's handling of requirements (dependencies). Basically,
> before installing a given package, it will fetch all that package's
> unsatisfied requirements; if that is successful it will remove them
> all, and then install them all., and finally install the originally
> requested package. 
>
> So the order of operations that you see depends very much on what
> you're installing, and which of its requirements are already installed.

I would not have asked if it wasn't for the fact that on both OS's it
was the exact same operation: an enpkg --update-all. I keep these 2
distributions update the same way, because I develop on my Macbook, but
am running heavy-duty stuff on the linux machine.

So, I'm thinking the update procedure should have looked the same,
because the same kind of packages were new (the list for the update was
indeed the same, at least as much as I could glance from a quick look).
If of course one package maybe was not yet installed on one OS why it
was installed on the other, maybe that would create the observed
difference.

Michael

>
> hth,
> Jonathan
>
>
> On Thu, Apr 4, 2013 at 1:39 PM, Jonathan March
> <[hidden email]> wrote:
> Michael,
>
> 1. Did Puneeth's suggestion work ok for you for getting the updates installed?
>
> 2. The fetch-remove-install cycle per package is the normal behavior.
> I'm surprised at what you report in Linux.
>
> 3. Your soft linking of the standard 32-bit install dir into the 64 dir
> is not necessarily a problem, especially since you don't have it
> anywhere on sys.path (e.g. from PYTHONPATH). But be aware that this can
> be risky, because Python's identification of modules is path-based, so
> if you somehow import the same module twice (once with each path),
> Python may import it twice separately; then stateful module-level
> objects would be repeated, and subtle bugs could ensue.
>
> 4. Self-compiled pure Python modules will be the same for 32- and
> 64-bit (indeed, for all platforms), so no problem there. But if they
> contain  any c extensions, you'll be in big trouble.
>
> hth,
> Jonathan
>
>
>
>
> On Wed, Apr 3, 2013 at 3:29 AM, Puneeth Chaganti
> <[hidden email]> wrote:
> Hi Michael,
>
> On Wed, Apr 3, 2013 at 7:12 AM, K.-Michael Aye
> <[hidden email]> wrote:
> [..]
> > AttributeError: 'unicode' object has no attribute 'name'
>
> Thanks for reporting the issue, and this should be fixed, soon.  I
> have sent a PR for this.  But, until then, you can just run the
> --update-all command repeatedly, until all your packages are updated.
>
> Hope that helps,
> Puneeth
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Michael Aye
In reply to this post by Jonathan March

On 2013-04-04 18:39:01 +0000, Jonathan March said:


Michael,


1. Did Puneeth's suggestion work ok for you for getting the updates installed?


On linux yes, on OSX it's still showing the same error:


()[maye@lunatic ~]$ sudo enpkg --update-all

The following updates and their dependencies will be installed

Name                 installed            available

============================================================

ets                  4.2.0-1              4.3.0-1

etsdevtools          4.0.0-1              4.0.2-1

codetools            4.0.0-1              4.1.0-1

scimath              4.1.0-1              4.1.2-1

encore               0.2-2                0.3-1

enaml                0.2.0-1              0.6.8-1

apptools             4.1.0-1              4.2.0-1

chaco                4.2.0-1              4.3.0-1

mayavi               4.2.0-1              4.3.0-1

pyface               4.2.0-1              4.3.0-1

Traceback (most recent call last):

  File "/Library/Frameworks/Python.framework/Versions/Current/bin/enpkg", line 10, in <module>

    sys.exit(main())

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py", line 634, in main

    update_all(enpkg, args)

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py", line 245, in update_all

    install_req(enpkg, update['current']['name'], args)

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py", line 387, in install_req

    _perform_install()

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py", line 308, in _perform_install

    if mode == 'root' or e.req is None or e.req == req:

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/resolve.py", line 89, in __eq__

    return (self.name == other.name  and

AttributeError: 'unicode' object has no attribute 'name'




2. The fetch-remove-install cycle per package is the normal behavior. I'm surprised at what you report in Linux.


3. Your soft linking of the standard 32-bit install dir into the 64 dir is not necessarily a problem, especially since you don't have it anywhere on sys.path (e.g. from PYTHONPATH). But be aware that this can be risky, because Python's identification of modules is path-based, so if you somehow import the same module twice (once with each path), Python may import it twice separately; then stateful module-level objects would be repeated, and subtle bugs could ensue.


Ok, I will consider other solutions.


4. Self-compiled pure Python modules will be the same for 32- and 64-bit (indeed, for all platforms), so no problem there. But if they contain  any c extensions, you'll be in big trouble.


Understood, thanks.


Michael



hth,

Jonathan





On Wed, Apr 3, 2013 at 3:29 AM, Puneeth Chaganti <[hidden email]> wrote:

Hi Michael,


On Wed, Apr 3, 2013 at 7:12 AM, K.-Michael Aye <[hidden email]> wrote:

[..]

> AttributeError: 'unicode' object has no attribute 'name'


Thanks for reporting the issue, and this should be fixed, soon.  I

have sent a PR for this.  But, until then, you can just run the

--update-all command repeatedly, until all your packages are updated.


Hope that helps,

Puneeth

_______________________________________________

Enthought-Dev mailing list

[hidden email]

https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________

Enthought-Dev mailing list

[hidden email]

https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Jonathan March



On Fri, Apr 5, 2013 at 12:50 AM, K.-Michael Aye <[hidden email]> wrote:

On 2013-04-04 18:39:01 +0000, Jonathan March said:


Michael,


1. Did Puneeth's suggestion work ok for you for getting the updates installed?


On linux yes, on OSX it's still showing the same error:


()[maye@lunatic ~]$ sudo enpkg --update-all

The following updates and their dependencies will be installed

Name                 installed            available

============================================================

ets                  4.2.0-1              4.3.0-1

etsdevtools          4.0.0-1              4.0.2-1

codetools            4.0.0-1              4.1.0-1

scimath              4.1.0-1              4.1.2-1

encore               0.2-2                0.3-1

enaml                0.2.0-1              0.6.8-1

apptools             4.1.0-1              4.2.0-1

chaco                4.2.0-1              4.3.0-1

mayavi               4.2.0-1              4.3.0-1

pyface               4.2.0-1              4.3.0-1

Traceback (most recent call last):

  File "/Library/Frameworks/Python.framework/Versions/Current/bin/enpkg", line 10, in <module>

    sys.exit(main())

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py", line 634, in main

    update_all(enpkg, args)

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py", line 245, in update_all

    install_req(enpkg, update['current']['name'], args)

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py", line 387, in install_req

    _perform_install()

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py", line 308, in _perform_install

    if mode == 'root' or e.req is None or e.req == req:

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/resolve.py", line 89, in __eq__

    return (self.name == other.name  and

AttributeError: 'unicode' object has no attribute 'name'


Interesting; I did not see this variation. I expect that the fix will be available later today.




2. The fetch-remove-install cycle per package is the normal behavior. I'm surprised at what you report in Linux.


3. Your soft linking of the standard 32-bit install dir into the 64 dir is not necessarily a problem, especially since you don't have it anywhere on sys.path (e.g. from PYTHONPATH). But be aware that this can be risky, because Python's identification of modules is path-based, so if you somehow import the same module twice (once with each path), Python may import it twice separately; then stateful module-level objects would be repeated, and subtle bugs could ensue.


Ok, I will consider other solutions.


4. Self-compiled pure Python modules will be the same for 32- and 64-bit (indeed, for all platforms), so no problem there. But if they contain  any c extensions, you'll be in big trouble.


Understood, thanks.


Michael



hth,

Jonathan





On Wed, Apr 3, 2013 at 3:29 AM, Puneeth Chaganti <[hidden email]> wrote:

Hi Michael,


On Wed, Apr 3, 2013 at 7:12 AM, K.-Michael Aye <[hidden email]> wrote:

[..]

> AttributeError: 'unicode' object has no attribute 'name'


Thanks for reporting the issue, and this should be fixed, soon.  I

have sent a PR for this.  But, until then, you can just run the

--update-all command repeatedly, until all your packages are updated.


Hope that helps,

Puneeth

_______________________________________________

Enthought-Dev mailing list

[hidden email]

https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________

Enthought-Dev mailing list

[hidden email]

https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Michael Aye
In reply to this post by Michael Aye
On 2013-04-05 05:50:55 +0000, K.-Michael Aye said:

> On 2013-04-04 18:39:01 +0000, Jonathan March said:
>
>> Michael,
>>
>> 1. Did Puneeth's suggestion work ok for you for getting the updates installed?
>
> On linux yes, on OSX it's still showing the same error:
>
> ()[maye@lunatic ~]$ sudo enpkg --update-all
> The following updates and their dependencies will be installed
> Name                 installed            available
> ============================================================
> ets                  4.2.0-1              4.3.0-1
> etsdevtools          4.0.0-1              4.0.2-1
> codetools            4.0.0-1              4.1.0-1
> scimath              4.1.0-1              4.1.2-1
> encore               0.2-2                0.3-1
> enaml                0.2.0-1              0.6.8-1
> apptools             4.1.0-1              4.2.0-1
> chaco                4.2.0-1              4.3.0-1
> mayavi               4.2.0-1              4.3.0-1
> pyface               4.2.0-1              4.3.0-1
> Traceback (most recent call last):
>   File
> "/Library/Frameworks/Python.framework/Versions/Current/bin/enpkg", line
> 10, in <module>
>     sys.exit(main())
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
> line 634, in main
>     update_all(enpkg, args)
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
> line 245, in update_all
>     install_req(enpkg, update['current']['name'], args)
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
> line 387, in install_req
>     _perform_install()
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
> line 308, in _perform_install
>     if mode == 'root' or e.req is None or e.req == req:
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/resolve.py",
> line 89, in __eq__
>     return (self.name == other.name  and
> AttributeError: 'unicode' object has no attribute 'name'


There's a big dependency mess going on with enpkg, I believe.
As you can see from below, ets does not install, because it wants
enable 4.3.0-1
But enable is already on 4.3.0-2 which seems to be refused by ets.



()[maye@lunatic ~]$ sudo enpkg ets
prefix: /Library/Frameworks/EPD64.framework/Versions/7.3
Error: could not resolve "enable 4.3.0-1" required by "ets-4.3.0-1.egg"
You may be able to force an install of just this egg by using the
--no-deps enpkg commandline argument after installing another version
of the dependency.
Available versions of the required package 'enable' are:
    4.0.0, 4.1.0, 4.2.0, 4.3.0
()[maye@lunatic ~]$ sudo enpkg enable
prefix: /Library/Frameworks/EPD64.framework/Versions/7.3
No update necessary, 'enable' is up-to-date.
enable-4.3.0-2.egg was installed on: Tue Apr  2 18:35:47 2013
()[maye@lunatic ~]$


Michael

>
>
>>
>> 2. The fetch-remove-install cycle per package is the normal behavior.
>> I'm surprised at what you report in Linux.
>>
>> 3. Your soft linking of the standard 32-bit install dir into the 64 dir
>> is not necessarily a problem, especially since you don't have it
>> anywhere on sys.path (e.g. from PYTHONPATH). But be aware that this can
>> be risky, because Python's identification of modules is path-based, so
>> if you somehow import the same module twice (once with each path),
>> Python may import it twice separately; then stateful module-level
>> objects would be repeated, and subtle bugs could ensue.
>
> Ok, I will consider other solutions.
>>
>> 4. Self-compiled pure Python modules will be the same for 32- and
>> 64-bit (indeed, for all platforms), so no problem there. But if they
>> contain  any c extensions, you'll be in big trouble.
>
> Understood, thanks.
>
> Michael
>
>>
>> hth,
>> Jonathan
>>
>>
>>
>>
>> On Wed, Apr 3, 2013 at 3:29 AM, Puneeth Chaganti
>> <[hidden email]> wrote:
>> Hi Michael,
>>
>> On Wed, Apr 3, 2013 at 7:12 AM, K.-Michael Aye <[hidden email]> wrote:
>> [..]
>> > AttributeError: 'unicode' object has no attribute 'name'
>>
>> Thanks for reporting the issue, and this should be fixed, soon.  I
>> have sent a PR for this.  But, until then, you can just run the
>> --update-all command repeatedly, until all your packages are updated.
>>
>> Hope that helps,
>> Puneeth
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>>
>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>>
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Jonathan March
In reply to this post by Jonathan March
Michael, the fixed version is now available.

On OSX:
sudo enpkg enstaller

Please let us know if this works for you.

Thanks,
Jonathan


On Fri, Apr 5, 2013 at 6:39 AM, Jonathan March <[hidden email]> wrote:



On Fri, Apr 5, 2013 at 12:50 AM, K.-Michael Aye <[hidden email]> wrote:

On 2013-04-04 18:39:01 +0000, Jonathan March said:


Michael,


1. Did Puneeth's suggestion work ok for you for getting the updates installed?


On linux yes, on OSX it's still showing the same error:


()[maye@lunatic ~]$ sudo enpkg --update-all

The following updates and their dependencies will be installed

Name                 installed            available

============================================================

ets                  4.2.0-1              4.3.0-1

etsdevtools          4.0.0-1              4.0.2-1

codetools            4.0.0-1              4.1.0-1

scimath              4.1.0-1              4.1.2-1

encore               0.2-2                0.3-1

enaml                0.2.0-1              0.6.8-1

apptools             4.1.0-1              4.2.0-1

chaco                4.2.0-1              4.3.0-1

mayavi               4.2.0-1              4.3.0-1

pyface               4.2.0-1              4.3.0-1

Traceback (most recent call last):

  File "/Library/Frameworks/Python.framework/Versions/Current/bin/enpkg", line 10, in <module>

    sys.exit(main())

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py", line 634, in main

    update_all(enpkg, args)

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py", line 245, in update_all

    install_req(enpkg, update['current']['name'], args)

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py", line 387, in install_req

    _perform_install()

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py", line 308, in _perform_install

    if mode == 'root' or e.req is None or e.req == req:

  File "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/resolve.py", line 89, in __eq__

    return (self.name == other.name  and

AttributeError: 'unicode' object has no attribute 'name'


Interesting; I did not see this variation. I expect that the fix will be available later today.




2. The fetch-remove-install cycle per package is the normal behavior. I'm surprised at what you report in Linux.


3. Your soft linking of the standard 32-bit install dir into the 64 dir is not necessarily a problem, especially since you don't have it anywhere on sys.path (e.g. from PYTHONPATH). But be aware that this can be risky, because Python's identification of modules is path-based, so if you somehow import the same module twice (once with each path), Python may import it twice separately; then stateful module-level objects would be repeated, and subtle bugs could ensue.


Ok, I will consider other solutions.


4. Self-compiled pure Python modules will be the same for 32- and 64-bit (indeed, for all platforms), so no problem there. But if they contain  any c extensions, you'll be in big trouble.


Understood, thanks.


Michael



hth,

Jonathan





On Wed, Apr 3, 2013 at 3:29 AM, Puneeth Chaganti <[hidden email]> wrote:

Hi Michael,


On Wed, Apr 3, 2013 at 7:12 AM, K.-Michael Aye <[hidden email]> wrote:

[..]

> AttributeError: 'unicode' object has no attribute 'name'


Thanks for reporting the issue, and this should be fixed, soon.  I

have sent a PR for this.  But, until then, you can just run the

--update-all command repeatedly, until all your packages are updated.


Hope that helps,

Puneeth

_______________________________________________

Enthought-Dev mailing list

[hidden email]

https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________

Enthought-Dev mailing list

[hidden email]

https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev




_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Michael Aye
In reply to this post by Michael Aye
On 2013-04-05 05:50:55 +0000, K.-Michael Aye said:

> On 2013-04-04 18:39:01 +0000, Jonathan March said:
>
>> Michael,
>>
>> 1. Did Puneeth's suggestion work ok for you for getting the updates installed?
>
> On linux yes, on OSX it's still showing the same error:
>
> ()[maye@lunatic ~]$ sudo enpkg --update-all
> The following updates and their dependencies will be installed
> Name                 installed            available
> ============================================================
> ets                  4.2.0-1              4.3.0-1
> etsdevtools          4.0.0-1              4.0.2-1
> codetools            4.0.0-1              4.1.0-1
> scimath              4.1.0-1              4.1.2-1
> encore               0.2-2                0.3-1
> enaml                0.2.0-1              0.6.8-1
> apptools             4.1.0-1              4.2.0-1
> chaco                4.2.0-1              4.3.0-1
> mayavi               4.2.0-1              4.3.0-1
> pyface               4.2.0-1              4.3.0-1
> Traceback (most recent call last):
>   File
> "/Library/Frameworks/Python.framework/Versions/Current/bin/enpkg", line
> 10, in <module>
>     sys.exit(main())
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
> line 634, in main
>     update_all(enpkg, args)
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
> line 245, in update_all
>     install_req(enpkg, update['current']['name'], args)
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
> line 387, in install_req
>     _perform_install()
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
> line 308, in _perform_install
>     if mode == 'root' or e.req is None or e.req == req:
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/resolve.py",
> line 89, in __eq__
>     return (self.name == other.name  and
> AttributeError: 'unicode' object has no attribute 'name'


I'm afraid there seems to be a dependency mess currently with enpkg:

(master)[maye@lunatic .../Dropbox/src/divl1b_calib]$ sudo enpkg --whats-new
Name                 installed            available
============================================================
ets                  4.2.0-1              4.3.0-2
etsdevtools          4.0.0-1              4.0.2-1
codetools            4.0.0-1              4.1.0-1
scimath              4.1.0-1              4.1.2-1
encore               0.2-2                0.3-1
enaml                0.2.0-1              0.6.8-1
apptools             4.1.0-1              4.2.0-1
chaco                4.2.0-1              4.3.0-1
mayavi               4.2.0-1              4.3.0-1
pyface               4.2.0-1              4.3.0-1
(master)[maye@lunatic .../Dropbox/src/divl1b_calib]$ sudo enpkg --update-all
The following updates and their dependencies will be installed
Name                 installed            available
============================================================
ets                  4.2.0-1              4.3.0-2
etsdevtools          4.0.0-1              4.0.2-1
codetools            4.0.0-1              4.1.0-1
scimath              4.1.0-1              4.1.2-1
encore               0.2-2                0.3-1
enaml                0.2.0-1              0.6.8-1
apptools             4.1.0-1              4.2.0-1
chaco                4.2.0-1              4.3.0-1
mayavi               4.2.0-1              4.3.0-1
pyface               4.2.0-1              4.3.0-1
Error: could not resolve "mayavi 4.3.0-2" required by "ets-4.3.0-2.egg"
You may be able to force an install of just this egg by using the
--no-deps enpkg commandline argument after installing another version
of the dependency.
Available versions of the required package 'mayavi' are:
    4.2.0, 4.3.0


>
>>
>> 2. The fetch-remove-install cycle per package is the normal behavior.
>> I'm surprised at what you report in Linux.
>>
>> 3. Your soft linking of the standard 32-bit install dir into the 64 dir
>> is not necessarily a problem, especially since you don't have it
>> anywhere on sys.path (e.g. from PYTHONPATH). But be aware that this can
>> be risky, because Python's identification of modules is path-based, so
>> if you somehow import the same module twice (once with each path),
>> Python may import it twice separately; then stateful module-level
>> objects would be repeated, and subtle bugs could ensue.
>
> Ok, I will consider other solutions.
>>
>> 4. Self-compiled pure Python modules will be the same for 32- and
>> 64-bit (indeed, for all platforms), so no problem there. But if they
>> contain  any c extensions, you'll be in big trouble.
>
> Understood, thanks.
>
> Michael
>
>>
>> hth,
>> Jonathan
>>
>>
>>
>>
>> On Wed, Apr 3, 2013 at 3:29 AM, Puneeth Chaganti
>> <[hidden email]> wrote:
>> Hi Michael,
>>
>> On Wed, Apr 3, 2013 at 7:12 AM, K.-Michael Aye <[hidden email]> wrote:
>> [..]
>> > AttributeError: 'unicode' object has no attribute 'name'
>>
>> Thanks for reporting the issue, and this should be fixed, soon.  I
>> have sent a PR for this.  But, until then, you can just run the
>> --update-all command repeatedly, until all your packages are updated.
>>
>> Hope that helps,
>> Puneeth
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>>
>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>>
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Jonathan March
Thanks for your reports and patience, Michael.

As I guess you observed, the ets:enable dependency error was fixed around the time that you reported it.
The ets:mayavi dependency error on OSX-64 should be resolved today.

Jonathan



On Fri, Apr 5, 2013 at 8:53 PM, K.-Michael Aye <[hidden email]> wrote:
On 2013-04-05 05:50:55 +0000, K.-Michael Aye said:

> On 2013-04-04 18:39:01 +0000, Jonathan March said:
>
>> Michael,
>>
>> 1. Did Puneeth's suggestion work ok for you for getting the updates installed?
>
> On linux yes, on OSX it's still showing the same error:
>
> ()[maye@lunatic ~]$ sudo enpkg --update-all
> The following updates and their dependencies will be installed
> Name                 installed            available
> ============================================================
> ets                  4.2.0-1              4.3.0-1
> etsdevtools          4.0.0-1              4.0.2-1
> codetools            4.0.0-1              4.1.0-1
> scimath              4.1.0-1              4.1.2-1
> encore               0.2-2                0.3-1
> enaml                0.2.0-1              0.6.8-1
> apptools             4.1.0-1              4.2.0-1
> chaco                4.2.0-1              4.3.0-1
> mayavi               4.2.0-1              4.3.0-1
> pyface               4.2.0-1              4.3.0-1
> Traceback (most recent call last):
>   File
> "/Library/Frameworks/Python.framework/Versions/Current/bin/enpkg", line
> 10, in <module>
>     sys.exit(main())
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
> line 634, in main
>     update_all(enpkg, args)
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
> line 245, in update_all
>     install_req(enpkg, update['current']['name'], args)
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
> line 387, in install_req
>     _perform_install()
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",
> line 308, in _perform_install
>     if mode == 'root' or e.req is None or e.req == req:
>   File
> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/resolve.py",
> line 89, in __eq__
>     return (self.name == other.name  and
> AttributeError: 'unicode' object has no attribute 'name'


I'm afraid there seems to be a dependency mess currently with enpkg:

(master)[maye@lunatic .../Dropbox/src/divl1b_calib]$ sudo enpkg --whats-new
Name                 installed            available
============================================================
ets                  4.2.0-1              4.3.0-2
etsdevtools          4.0.0-1              4.0.2-1
codetools            4.0.0-1              4.1.0-1
scimath              4.1.0-1              4.1.2-1
encore               0.2-2                0.3-1
enaml                0.2.0-1              0.6.8-1
apptools             4.1.0-1              4.2.0-1
chaco                4.2.0-1              4.3.0-1
mayavi               4.2.0-1              4.3.0-1
pyface               4.2.0-1              4.3.0-1
(master)[maye@lunatic .../Dropbox/src/divl1b_calib]$ sudo enpkg --update-all
The following updates and their dependencies will be installed
Name                 installed            available
============================================================
ets                  4.2.0-1              4.3.0-2
etsdevtools          4.0.0-1              4.0.2-1
codetools            4.0.0-1              4.1.0-1
scimath              4.1.0-1              4.1.2-1
encore               0.2-2                0.3-1
enaml                0.2.0-1              0.6.8-1
apptools             4.1.0-1              4.2.0-1
chaco                4.2.0-1              4.3.0-1
mayavi               4.2.0-1              4.3.0-1
pyface               4.2.0-1              4.3.0-1
Error: could not resolve "mayavi 4.3.0-2" required by "ets-4.3.0-2.egg"
You may be able to force an install of just this egg by using the
--no-deps enpkg commandline argument after installing another version
of the dependency.
Available versions of the required package 'mayavi' are:
    4.2.0, 4.3.0


>
>>
>> 2. The fetch-remove-install cycle per package is the normal behavior.
>> I'm surprised at what you report in Linux.
>>
>> 3. Your soft linking of the standard 32-bit install dir into the 64 dir
>> is not necessarily a problem, especially since you don't have it
>> anywhere on sys.path (e.g. from PYTHONPATH). But be aware that this can
>> be risky, because Python's identification of modules is path-based, so
>> if you somehow import the same module twice (once with each path),
>> Python may import it twice separately; then stateful module-level
>> objects would be repeated, and subtle bugs could ensue.
>
> Ok, I will consider other solutions.
>>
>> 4. Self-compiled pure Python modules will be the same for 32- and
>> 64-bit (indeed, for all platforms), so no problem there. But if they
>> contain  any c extensions, you'll be in big trouble.
>
> Understood, thanks.
>
> Michael
>
>>
>> hth,
>> Jonathan
>>
>>
>>
>>
>> On Wed, Apr 3, 2013 at 3:29 AM, Puneeth Chaganti
>> <[hidden email]> wrote:
>> Hi Michael,
>>
>> On Wed, Apr 3, 2013 at 7:12 AM, K.-Michael Aye <[hidden email]> wrote:
>> [..]
>> > AttributeError: 'unicode' object has no attribute 'name'
>>
>> Thanks for reporting the issue, and this should be fixed, soon.  I
>> have sent a PR for this.  But, until then, you can just run the
>> --update-all command repeatedly, until all your packages are updated.
>>
>> Hope that helps,
>> Puneeth
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>>
>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>>
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Michael Aye-2
In reply to this post by Michael Aye
Sorry for the multiple posts before, I didn't see mine so I thought
they got lost.

I report that the update problem on OSX has been solved.

Michael


On 2013-04-05 19:14:33 +0000, K.-Michael Aye said:

> On 2013-04-05 05:50:55 +0000, K.-Michael Aye said:
>
>> On 2013-04-04 18:39:01 +0000, Jonathan March said:
>>
>>> Michael,
>>>
>>> 1. Did Puneeth's suggestion work ok for you for getting the updates installed?
>>
>> On linux yes, on OSX it's still showing the same error:
>>
>> ()[maye@lunatic ~]$ sudo enpkg --update-all
>> The following updates and their dependencies will be installed
>> Name                 installed            available
>> ===========================================================> ets        
>>           4.2.0-1              4.3.0-1
>> etsdevtools          4.0.0-1              4.0.2-1
>> codetools            4.0.0-1              4.1.0-1
>> scimath              4.1.0-1              4.1.2-1
>> encore               0.2-2                0.3-1
>> enaml                0.2.0-1              0.6.8-1
>> apptools             4.1.0-1              4.2.0-1
>> chaco                4.2.0-1              4.3.0-1
>> mayavi               4.2.0-1              4.3.0-1
>> pyface               4.2.0-1              4.3.0-1
>> Traceback (most recent call last):
>> File>
>> "/Library/Frameworks/Python.framework/Versions/Current/bin/enpkg",
>> line> 10, in <module>
>> sys.exit(main())
>> File>
>> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",>
>> line 634, in main
>> update_all(enpkg, args)
>> File>
>> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",>
>> line 245, in update_all
>> install_req(enpkg, update['current']['name'], args)
>> File>
>> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",>
>> line 387, in install_req
>> _perform_install()
>> File>
>> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",>
>> line 308, in _perform_install
>> if mode == 'root' or e.req is None or e.req == req:
>> File>
>> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/resolve.py",>
>> line 89, in __eq__
>> return (self.name == other.name  and
>> AttributeError: 'unicode' object has no attribute 'name'
>
>
> There's a big dependency mess going on with enpkg, I believe.
> As you can see from below, ets does not install, because it wantsenable 4.3.0-1
> But enable is already on 4.3.0-2 which seems to be refused by ets.
>
>
>
> ()[maye@lunatic ~]$ sudo enpkg ets
> prefix: /Library/Frameworks/EPD64.framework/Versions/7.3
> Error: could not resolve "enable 4.3.0-1" required by "ets-4.3.0-1.egg"
> You may be able to force an install of just this egg by using the
> --no-deps enpkg commandline argument after installing another version
> of the dependency.
> Available versions of the required package 'enable' are:
>     4.0.0, 4.1.0, 4.2.0, 4.3.0
> ()[maye@lunatic ~]$ sudo enpkg enable
> prefix: /Library/Frameworks/EPD64.framework/Versions/7.3
> No update necessary, 'enable' is up-to-date.
> enable-4.3.0-2.egg was installed on: Tue Apr  2 18:35:47 2013
> ()[maye@lunatic ~]$
>
>
> Michael
>
>>
>>
>>>
>>> 2. The fetch-remove-install cycle per package is the normal behavior.>>
>>> I'm surprised at what you report in Linux.
>>>
>>> 3. Your soft linking of the standard 32-bit install dir into the 64
>>> dir>> is not necessarily a problem, especially since you don't have
>>> it>> anywhere on sys.path (e.g. from PYTHONPATH). But be aware that
>>> this can>> be risky, because Python's identification of modules is
>>> path-based, so>> if you somehow import the same module twice (once with
>>> each path),>> Python may import it twice separately; then stateful
>>> module-level>> objects would be repeated, and subtle bugs could ensue.
>>
>> Ok, I will consider other solutions.
>>>
>>> 4. Self-compiled pure Python modules will be the same for 32- and>>
>>> 64-bit (indeed, for all platforms), so no problem there. But if they>>
>>> contain  any c extensions, you'll be in big trouble.
>>
>> Understood, thanks.
>>
>> Michael
>>
>>>
>>> hth,
>>> Jonathan
>>>
>>>
>>>
>>>
>>> On Wed, Apr 3, 2013 at 3:29 AM, Puneeth Chaganti>>
>>> <[hidden email]> wrote:
>>> Hi Michael,
>>>
>>> On Wed, Apr 3, 2013 at 7:12 AM, K.-Michael Aye
>>> <[hidden email]> wrote:
>>> [..]
>>>> AttributeError: 'unicode' object has no attribute 'name'
>>>
>>> Thanks for reporting the issue, and this should be fixed, soon.  I
>>> have sent a PR for this.  But, until then, you can just run the
>>> --update-all command repeatedly, until all your packages are updated.
>>>
>>> Hope that helps,
>>> Puneeth
>>> _______________________________________________
>>> Enthought-Dev mailing list
>>> [hidden email]>>>>
>>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>>>
>>> _______________________________________________
>>> Enthought-Dev mailing list
>>> [hidden email]
>>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>>
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>> https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: ets update to 4.3 fails

Jonathan March
Thanks for confirming and for your patience, Michael.


On Wed, Apr 10, 2013 at 5:11 PM, Michael Aye <[hidden email]> wrote:
Sorry for the multiple posts before, I didn't see mine so I thought
they got lost.

I report that the update problem on OSX has been solved.

Michael


On 2013-04-05 19:14:33 +0000, K.-Michael Aye said:

> On 2013-04-05 05:50:55 +0000, K.-Michael Aye said:
>
>> On 2013-04-04 18:39:01 +0000, Jonathan March said:
>>
>>> Michael,
>>>
>>> 1. Did Puneeth's suggestion work ok for you for getting the updates installed?
>>
>> On linux yes, on OSX it's still showing the same error:
>>
>> ()[maye@lunatic ~]$ sudo enpkg --update-all
>> The following updates and their dependencies will be installed
>> Name                 installed            available
>> ===========================================================> ets
>>           4.2.0-1              4.3.0-1
>> etsdevtools          4.0.0-1              4.0.2-1
>> codetools            4.0.0-1              4.1.0-1
>> scimath              4.1.0-1              4.1.2-1
>> encore               0.2-2                0.3-1
>> enaml                0.2.0-1              0.6.8-1
>> apptools             4.1.0-1              4.2.0-1
>> chaco                4.2.0-1              4.3.0-1
>> mayavi               4.2.0-1              4.3.0-1
>> pyface               4.2.0-1              4.3.0-1
>> Traceback (most recent call last):
>> File>
>> "/Library/Frameworks/Python.framework/Versions/Current/bin/enpkg",
>> line> 10, in <module>
>> sys.exit(main())
>> File>
>> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",>
>> line 634, in main
>> update_all(enpkg, args)
>> File>
>> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",>
>> line 245, in update_all
>> install_req(enpkg, update['current']['name'], args)
>> File>
>> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",>
>> line 387, in install_req
>> _perform_install()
>> File>
>> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/main.py",>
>> line 308, in _perform_install
>> if mode == 'root' or e.req is None or e.req == req:
>> File>
>> "/Library/Frameworks/EPD64.framework/Versions/7.3/lib/python2.7/site-packages/enstaller/resolve.py",>
>> line 89, in __eq__
>> return (self.name == other.name  and
>> AttributeError: 'unicode' object has no attribute 'name'
>
>
> There's a big dependency mess going on with enpkg, I believe.
> As you can see from below, ets does not install, because it wantsenable 4.3.0-1
> But enable is already on 4.3.0-2 which seems to be refused by ets.
>
>
>
> ()[maye@lunatic ~]$ sudo enpkg ets
> prefix: /Library/Frameworks/EPD64.framework/Versions/7.3
> Error: could not resolve "enable 4.3.0-1" required by "ets-4.3.0-1.egg"
> You may be able to force an install of just this egg by using the
> --no-deps enpkg commandline argument after installing another version
> of the dependency.
> Available versions of the required package 'enable' are:
>     4.0.0, 4.1.0, 4.2.0, 4.3.0
> ()[maye@lunatic ~]$ sudo enpkg enable
> prefix: /Library/Frameworks/EPD64.framework/Versions/7.3
> No update necessary, 'enable' is up-to-date.
> enable-4.3.0-2.egg was installed on: Tue Apr  2 18:35:47 2013
> ()[maye@lunatic ~]$
>
>
> Michael
>
>>
>>
>>>
>>> 2. The fetch-remove-install cycle per package is the normal behavior.>>
>>> I'm surprised at what you report in Linux.
>>>
>>> 3. Your soft linking of the standard 32-bit install dir into the 64
>>> dir>> is not necessarily a problem, especially since you don't have
>>> it>> anywhere on sys.path (e.g. from PYTHONPATH). But be aware that
>>> this can>> be risky, because Python's identification of modules is
>>> path-based, so>> if you somehow import the same module twice (once with
>>> each path),>> Python may import it twice separately; then stateful
>>> module-level>> objects would be repeated, and subtle bugs could ensue.
>>
>> Ok, I will consider other solutions.
>>>
>>> 4. Self-compiled pure Python modules will be the same for 32- and>>
>>> 64-bit (indeed, for all platforms), so no problem there. But if they>>
>>> contain  any c extensions, you'll be in big trouble.
>>
>> Understood, thanks.
>>
>> Michael
>>
>>>
>>> hth,
>>> Jonathan
>>>
>>>
>>>
>>>
>>> On Wed, Apr 3, 2013 at 3:29 AM, Puneeth Chaganti>>
>>> <[hidden email]> wrote:
>>> Hi Michael,
>>>
>>> On Wed, Apr 3, 2013 at 7:12 AM, K.-Michael Aye
>>> <[hidden email]> wrote:
>>> [..]
>>>> AttributeError: 'unicode' object has no attribute 'name'
>>>
>>> Thanks for reporting the issue, and this should be fixed, soon.  I
>>> have sent a PR for this.  But, until then, you can just run the
>>> --update-all command repeatedly, until all your packages are updated.
>>>
>>> Hope that helps,
>>> Puneeth
>>> _______________________________________________
>>> Enthought-Dev mailing list
>>> [hidden email]>>>>
>>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>>>
>>> _______________________________________________
>>> Enthought-Dev mailing list
>>> [hidden email]
>>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>>
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>> https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev