in new arrangement, why plugin_name folder is at all required?

[V S Rawat]

should I move python27.dll to programdata - npp - py folder?

[PeterJones]

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). When I removed it from the path, then my portables no longer worked when the two dll’s were both in the subdirectories…

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.

[V S Rawat]

@PeterJones said:

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.

[PeterJones]

@V-S-Rawat,

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.

[PeterJones]

@V-S-Rawat said,

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.

[Meta Chuh]

@PeterJones

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

[Meta Chuh]

added note regarding:

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 😉 ;-)

[V S Rawat]

Because npp has changed its arrangement, it is npp developers’ responsibility to ensure that plugins are installed properly and everything goes to its default new locations.

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.

[V S Rawat]

for that matter, I think all plugin related thinggies should be made to reside in programdata folder of that plugin-name.

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.

[Meta Chuh]

@V-S-Rawat

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)

[V S Rawat]

oh my gawd. confusion.

thanks for timely advice.

[PeterJones]

@V-S-Rawat said,

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.