password after import statement

[rawmean]

import pyapl works by from pynapl import APL asks for password. What am I doing wrong? What password is it asking for. I'm on Mac. Thanks!

[rodrigogiraoserrao]

You run both those import statements from the same directory, and one asks for a password and the other doesn't?

The statement from pynapl import APL runs the code in APL.py (which will run code in other files, in turn) whereas the statement import pynapl doesn't, so the file APL.py (or some other, imported by it) is probably running something that requires some level of privilege... I'll venture a wild guess and say it's the code that tries to locate the Dyalog app...

Have you tried typing your password? If so, did Py'n'APL start correctly?

On Sat, 30 Jul 2022, 00:34 Ramin, @.***> wrote:

import pyapl works by from pynapl import APL asks for password. What am I doing wrong? What password is it asking for. I'm on Mac. Thanks!

— Reply to this email directly, view it on GitHub https://github.com/Dyalog/pynapl/issues/22, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABK4OZJ2XJEO7STR4LSF6UDVWRTARANCNFSM55CH2LWQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[rawmean]

You are right; import pynapl also required password. It doesn't complain after I enter the machine password (this is the only module that asks for machine password. Have you tried it on a macOS?). It doesn't seem to be able to find APL.py. I've even copied a local version of the file in the current folder. Can you please advise on proper installation procedure? I'm using anaconda.

[0racle]

I have this same issue, running under WSL2. Why is this module even asking for a password on import?

[rodrigogiraoserrao]

It is highly likely that the issue is coming from the fact that the current pynapl will use a temporary auxiliary file when starting the connection between APL and Python, and it must be trying to write that file to a folder it doesn't have access to. This issue is being addressed.

This is the temporary auxiliary file:

https://github.com/Dyalog/pynapl/blob/7e47c04711a3f4d0c3587fb428f3aefe736006fb/pynapl/RunDyalog.py#L18-L26

And this is where it's being written:

https://github.com/Dyalog/pynapl/blob/7e47c04711a3f4d0c3587fb428f3aefe736006fb/pynapl/RunDyalog.py#L181

[0racle]

I think the issue is not with the actual pynapl package at all. I had installed is via pip (PyPI) which installs a completely different library. Of some minor concern, the pynapl package on PyPI attempts to send an email, but looking over the code, it doesn't look like it sends any sensitive/user data. It looks like maybe the module on PyPI is a student project just trying to send a test email via Gmail's SMTP.

There is a risk that this other module could be modified to do something malicious, and people attempting to interface Python and APL will install this other module.

It's recommended that this project either attempt to gain ownership of the pynapl name on PyPI, or rename and claim the new name on PyPI.

[rodrigogiraoserrao]

Excellent investigation. I see pynapl taken on PyPI as a completely unrelated library. I will reach out to the owner of that name and see if they'd be willing to give up the name so we can take it.

@rawmean this might've been your issue as well.