It is odd that C:\Program Files\Notepad++\plugins\PythonScript\scripts is having py scripts because that would mean uac hassles on each edit of our py script.

The historic (pre-7.6.x) configuration for PythonScript had two locations for storing the scripts: the “machine scripts” were stored in the plugins\PythonScript\scripts\ subdirectory of the installed-notead++ directory; the “user scripts” go in %AppData%\Notepad++\plugins\config\PythonScript\scripts\ . In case you’re curious, “machine scripts” mean the scripts that are available to every user of the machine (ie, global or public scripts); “user scripts” are scripts available just to the particular user.

Because of this configuration, if a machine with a pre-7.6.x installation had “machine scripts” and had UAC enabled, such that mere-mortal users needed to elevate to Admin before being able to install programs, then their “machine scripts” also had the same UAC requirements. Since with the 7.6.2 setup also puts machine scripts in the installed folder hierarchy (see @Meta-Chuh’s summary of locations for 7.6.2), then it still has UAC requirements for machine scripts. Nothing is changed in that regard. If you don’t want to deal with UAC for the stored scripts in PythonScript, make them as user scripts, not as machine scripts – that was true in 7.5.8, and it’s still true in 7.6.2.

thanks for timely advice.

I am moving python27.dll to programdata folder, and shall report if anything breaks down.

before you report a breakdown 😉:
as mentioned by @PeterJones and me, python27.dll has to be in the notepad++ installation folder.
it has to be at the same folder level where your notepad++.exe is located.
(unless you already have it in your system’s path, like inside of c:\windows or c:\windows\system32)

so I think entire C:\Program Files\Notepad++\plugins\PythonScript folder, having bulky lib and tiny scripts folders should go to programdata folder.

It is odd that C:\Program Files\Notepad++\plugins\PythonScript\scripts is having py scripts because that would mean uac hassles on each edit of our py script.

I am not sure whether programdata is also under uac hassles.

In that case user py scripts should be better left in c:\Users folder, just to avoid uac issues. Some method should be devised.

as long as things are “single location”, C:\Program Files\Notepad++\plugins folder and Programdata-plugins folder, two folders with same name would create confusion for users.

Thanks.

If the above is left to plugin developers, it will make them have to release different plugin versions for different npp versions, that would increase confusion.

maybe this forum can help new user and tell which file should be moved to which new default location, till enough new npp versions are released and most of us move to new plugin arrangement, so developers need not cater to older plugin arrangement.

I am moving python27.dll to programdata folder, and shall report if anything breaks down.

thanks.

you were not wrong in this case

reason for the added note:
because if i’d have said that same sentence to my girlfriend, she would say:
“so now you want to tell me that i was right today, but wrong every single time in the past, or what ?!?!?” 😂😂😂

and finally the added note itself:
in fact, my brain doesn’t even recall you to ever be wrong, if all cases where insufficient or wrong data was given in the first place are excluded.
(side note: that statement could either be a pro to you or a con to my brain 😉 ;-)

… and the root cause of why I was wrong.

don’t be that harsh on yourself. my faux-pas from this week is a llllooooottt more embarrassing.
and you were not wrong in this case, as you have explicitly tested it and it worked this way in your testing environment.

me on the other hand: today i found out that proxy support for plugins admin exists since day one, but i told a user, that plugins admin can not be used with a proxy server … what a statement …

luckily he reported back that he found the proxy setting, set it and it works at his office … i will apologise there in a few minutes.

so, it contradicts Peter’s assertion above that all plugin related dll are to be kept in programdata folder of plugin name.

I never made any claim about programdata folder. The only times I have used the word programdata in this thread are either when I quoted you, or in this post I am currently typing.

My post from yesterday incorrectly asserted that a portable version would allow both PythonScript.dll and python27.dll “in the portable’s plugins/PythonScript subdir”, but @Meta-Chuh already pointed out that was incorrect, and I’ve confirmed his correction, and the root cause of why I was wrong.

Sorry, you were posting at the same time I was posting/editing, so things got a little confused there.

To revise my statement yesterday, about where python27.dll resides: “python27.dll by default resides in the same directory as notepad++.exe, but it can exist anywhere else in the PATH.”

The current setup for PythonScript, where the python27.dll cannot just reside in the same location as PythonScript.dll, is compatible with Notepad++ before 7.6 (so 7.5.9 and earlier; I don’t know the earliest compatibility for any given version of PythonScript). It is also compatible with portable versions of Notepad++ that are newer (verified with 7.6.1 and 7.6.2) as long as the PythonScript.dll is kept in the new-NPP-compatible hierarchy of ...\plugins\PythonScript\PythonScript.dll, and as long as the python27.dll is either in the same folder as notepad++.exe for the portable, or somewhere in your path.

Based on these experiments, it will not be compatible with a 7.6.2 installed in the Program Files or Program Files (x86) hierarchy, unless someone with Admin privileges also does the plugin install and puts the python27.dll in an acceptable location.

You mentioned “It would be a bug if npp checks only pythonscript.dll’s presense in programdata”: but we weren’t talking about the pythonscript.dll: that can successfully go in ...\plugins\PythonScript\PythonScript.dll, as @Meta-Chuh mentioned above.

Saying “npp should force all plugin developers to use the new arrangement” is not really possible: All plugin developers only need to make their plugins compatible with whatever version(s) of Notepad++ they want their plugins to be compatible with. If any plugin developer wants to keep their plugin compatible only for 7.5.9 and earlier, that is their prerogative. If any plugin developer chooses to only make their plugin compatible with non-installed portable versions of Notepad++, there is nothing that Notepad++ should do about it. If any plugin developer chooses to not make their plugin compatible with Plugin Admin, and instead just give complicated manual-install instructions that may require Admin privileges, great. If burderstein chooses not to update where python27.dll is allowed to live (and make any other changes required for full compatibility, such as @Meta-Chuh mentioned), then PythonScript will be more difficult to install for those with non-portable Notepad++… but that is bruderstein’s choice.

Sneaky. It was in my path twice: once for my installed Notepad++, and once for another application (which used 2.7.5 instead of 2.7.15).

So, I retract what I said earlier about python27.dll being able to live in the same directory as the PythonScript.dll: sorry for the wrong information.

but what you said should have happened.

it would be a bug if npp checks only pythonscript.dll’s presence in programdata.
npp should force all plugin developers to use new arrangement.

So, I retract what I said earlier about python27.dll being able to live in the same directory as the PythonScript.dll: sorry for the wrong information.

python27.dll goes to:
%ProgramFiles(x86)%\Notepad++\python27.dll

yes, I also found that in my program files folder (64 bit)

so, it contradicts Peter’s assertion above that all plugin related dll are to be kept in programdata folder of plugin name.

thanks.

PythonScript.dll, plugin dll goes to:
%ProgramData%\Notepad++\plugins\PythonScript\PythonScript.dll

python27.dll goes to:
%ProgramFiles(x86)%\Notepad++\python27.dll

machine level scripts and python library go to:
%ProgramFiles(x86)%\Notepad++\plugins\PythonScript\lib\
%ProgramFiles(x86)%\Notepad++\plugins\PythonScript\scripts\
   contains sample scripts and startup.py

manual, context-help files go to:
%ProgramFiles(x86)%\Notepad++\plugins\doc\PythonScript\
   contains PythonScript.chm up to version 1.2.0.0
   contains html docs since version 1.3.0.0

user level scripts go to:
%AppData%\Notepad++\plugins\config\PythonScript\scripts\
   this folder will be created automatically as soon as a new script is created.

note on needed paths:
many paths inside pythonscript are hard coded and writing to %INSTALLDIR% is required to re-create historic folders and install this plugin, so i guess this plugin will probably never be added to the plugins admin list.
(unless bruderstein adapts it to suit the new folder structure and submits it to plugins admin … which officially deprecated his own plugin manager … echo hope >> nul 😉)

note on python27.dll:
on my portable and installed 7.6.2 test setups, python27.dll had to be inside the same folder where notepad++.exe is located (notepad++ program folder) except if python27.dll is already present somewhere inside the system’s %PATH%.

@PeterJones: could you please check if the system where you conducted the tests has a python27.dll elsewhere, or check what happens if you delete your portable version’s .dll from plugins/PythonScript/ ?

For portable, I have confirmed with 7.6.2 with a manual plugin install with both DLL in the portable’s plugins/PythonScript subdir that it can see it when it’s in the same dir as the pythonscript.dll.

I have never tried with the new Plugin Admin under an installed 7.6.2.

because I have only PythonScript.dll in programdata, and no dll in programfiles (unless lib has that).

and my addon is working.

every plugin has just one dll

Wrong, and easily falsifiable with a single counter-example: PythonScript has pythonscript.dll and python27.dll. Thus, not “every” plugin has just one dll.

Many plugins also come with other files, including help files, readme.txt files, and more. Can you guarantee that none of those will ever have name collisions (especially readme.txt)? That, in and of itself, is a good reason for a folder per plugin.