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 <#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:

pynapl/pynapl/RunDyalog.py

Lines 18 to 26 in 7e47c04

	script="""
	⎕PW←32767
	{}2⎕FIX'file://%s'
	{}2⎕FIX'file://%s'
	infile←'%s'
	outfile←'%s'
	Py.StartAPLSlave infile outfile
	)OFF
	"""

And this is where it's being written:

pynapl/pynapl/RunDyalog.py

Line 181 in 7e47c04

with open(to_bytes(os.path.dirname(SCRIPTFILE))+b'/WinPort.dyalog', "wb") as f:

[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.