Confused with installing per-user in Windows

2016-11-06 Thread ddbug
Dear experts,

I need to install some scripts for current user (to skip sudo, UAC popups and 
whatever).

So I make a sdist and use python -m pip install --user 

This should work for either Python 2 or 3.

On Linux, pip installs the scripts into ~/.local/bin ; users are instructed to 
add this to their PATH if they have not done so already.

In Windows, the user-local directory for scripts is %APPDATA%\Python\Scripts. 
It is not in PATH by default and finding it is hard (because Microsoft made it 
hidden in their infinite wisdom).

But more to this, either Python (2.7 or 3.5) will NOT look there by default. 
When user types "python myscript.py" or "py myscript.py" he is baffled by "not 
found".

Now, the question: 

1. would it be good if python interpreter could JUST find user-local scripts - 
by default or by some easy configuration option?

2. If not, would it be good to put this smartness into the PY.EXE launcher, 
make this behavior default or by a simple command line option?

So that user can be instructed to type "py myscript [.py]"  and it will JUST 
work, if the script is on existing PATH or in the per-user directory?


I know about bdist_wininst and Windows specific install options, but prefer 
single sdist installer whenever possible.

Thanks for reading.

--d
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Confused with installing per-user in Windows

2016-11-06 Thread ddbug
So basically I want to modify py.exe to not only detect the Python version from 
a script file, but also help locating the script file.

-- d
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: What is currently the recommended way to work with a distutils-based setup.py that requires compilation?

2016-11-09 Thread ddbug
I am a Python beginner but would like to contribute $0.02 in absence of 
authoritative answers (thanks Tim J. for encouragement).

After researching this topic for a while, it looks like they now recommend 
distributing wheels rather than sdist's.

For Windows thus is reasonable, given that there is no C/C++ compiler that is 
'standard' and easy to install, and also because pre-compiled binaries can be 
signed.

Regards,
-- dd
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Confused with installing per-user in Windows

2016-11-09 Thread ddbug
@eryk sun: Thank you for useful reply.

But note that I don't propose to touch the python interpeters (python*.exe), 
neither to change anything in how distutils work (about entry points).

My proposal is only for the Windows-specific Py launcher. For those who runs 
python*.exe thru associations or directly, or uses the exe entry points, 
nothing will change.

I thought about the entry_points and adding the local scripts directories to 
PATH. For myself, this is totally good idea. But for users, I am not so sure. 
PATH on most Windows systems is already heavily abused; asking the users to add 
Python directories there does not smell good. 


About Python/Python35/Scripts: point taken. But what is the user updates to 
3.6? Mess with the PATH again? IMHO a single fixup in PY.exe can help with this 
issue in the most simple and robust way.

As for LOCALAPPDATA vs APPDATA, I agree.

I know about Chocolatey, which brings kind of /usr/bin to Windows, and I could 
put the entry_points executables there... but again, I cannot ask user to 
install it.


Regards,

-- dd

p.s 
About .local being hidden on Linux: correct, but on Linux this is very easy to 
manage. Just create a link ~/bin pointing to ~/.local/bin and it will be 
automatically added in PATH. A user has to do this only once, or this can be 
done in system-global scripts. This should be good with entry_points.
-- 
https://mail.python.org/mailman/listinfo/python-list


How to access installed scripts on Windows?

2017-02-18 Thread ddbug
I am very perplexed by inability to tell the Windows installer (bdist_wininst 
or pip) where to install scripts (or "entry points").

By default (and I don't see other options) scripts go to 
%USERPROFILE%/Appdata/Roaming/Python/Scripts.

Ok. Now what? How the user is going to call these scripts: add this location to 
PATH? Then, should I add a custom script for this into the bdist_wininst 
installer?  It looks like the "py" launcher does not help to find scripts that 
are installed into that per-user location. 

What is the "best known good" method to easily run scripts installed in 
per-user location, from command line (aka "dos window") ?

Thanks,
Pavel A




-- 
https://mail.python.org/mailman/listinfo/python-list


Re: How to access installed scripts on Windows?

2017-03-04 Thread ddbug
Thank you eryk sun for the reply.

I am not so concerned by installing modules as by installing scripts ('entry 
points'). Per user.

If the Windows GUI installer can add the per-user script dirs to PATH it may be 
acceptable solution.

> The installer has an option to update PATH to include
> this Scripts directory.
> 

Is this the checkbox on the Advanced Options page, "Add Python to environment 
variables"?  
 
In my copy of 64-bit v3.6 installer this is UNchecked by default, and the text 
looks a bit vague. Might read more precise.

> You can also develop using venv virtual environments. You can symlink
> or shell-shortcut to the activation script of a virtual environment.
>

Interesting idea. But I have not seen any installers or guidance how to deploy 
something packaged as a venv to users. Can you share any pointers please?
 
> I dislike the idea of automatically searching script directories, but
> there could be a command-line option for this.
 
I agree, but the current situation is dire IMHO. One of fundamental Python 
batteries is leaking :-(

Right now I'm looking at IDLE and trying to figure out whether it can be used 
to solve this problem (like, run IDLE with a special start script or extension 
that will make these user-local scripts easy discoverable  Maybe a 
extension that adds a new GUI menu etc. )

Regards,
ddbug
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Basic Packaging strategy question

2017-03-04 Thread ddbug
On Sunday, March 5, 2017 at 1:08:25 AM UTC+2, [email protected] wrote:
> I have a simple project that I want to package to put it on another machine 
> but everything I have read so far about packaging ends up putting the whole 
> install alongside  with 'packages' - typically in .../site-packages. 
> This seems a strange place to launch an app from!
 
If your target OS is Windows - this is the question I have for long time 
without any good answer
(see this thread: 
https://groups.google.com/forum/#!topic/comp.lang.python/Gwx6HA83bUE )

There is a zillion ways to specify modules search path, but no good options on 
Windows to place entry points. One cannot consider dropping entry points in 
obscure places where user cannot find them, as good. Since on Linux this is not 
an issue (or much lesser issue) it can be viewed as one of deficiencies of 
Windows - but otherwise Python has 1st class support for Windows, including the 
cute py launcher.

> So, if I have an app with a main.py entry point is it ok for everything to be 
> in .../site-packages/myproject?

Nope, site-packages is the place for modules. You're asking about entry points. 

> Or, should I put everything except main.py in a package and then copy main.py 
> wherever I want and use PIP to install the package containing the rest of the 
> app?
>  
> simple example which ends up with needing to run:
>  python /usr/local/lib/site_packages/myproject/main.py:

Placing scripts under modules location is an option, and setuptools can 
automatically create 'entry points' that bootstrap the actual scripts.
But this does not solve the root issue - where to place these entry points?
 
I have not found a good solution yet.

Regards,

ddbug
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: How to access installed scripts on Windows?

2017-03-10 Thread ddbug
On Monday, March 6, 2017 at 12:29:54 PM UTC+2, Paul  Moore wrote:
> On Sunday, 5 March 2017 22:26:17 UTC, eryk sun  wrote:
> > On Sun, Mar 5, 2017 at 2:35 AM, ddbug  wrote:
.

Thank you Paul and Eryk for your replies.

My goal is definitely to expose the Python to my users. I want them to read 
the code and modify as needed - much like people use shell scripts in Linux - 
but I cannot expect them to install a heavy IDE. This is surprisingly easy in 
Ubuntu. The 'default' pip installer just does the right thing. The scripts go 
where the user expects them to be (~/bin or ~/.local/bin) - everything just 
works. I want to achieve the same on Windows - and hit a small but annoying 
obstacle: the default install location is not on PATH and not easy 
discoverable. 

Zipped applications is a good option (provides isolation and easier to grasp 
than virtualenvs) - but then I can stop using pip as deployment method and tell 
the users to check out my stuff from our version control system to the location 
of their choice. If their working copy is not in PATH - no problem.

If/when we start to use 3rd party dependencies, I'll have to add the 
dependencies to my repository (kind of virtualenv) or ... learn to use the real 
virtualenv.

I'm now looking at IDLE, trying to understand if it may be helpful for my 
Windows users for quick start. It is *almost* useful - but small crucial bit is 
missing again: no Change directory command in the GUI! and no easy way to 
specify a small 'set-up' code snippet for startup and every reset of the shell. 
This seems possible via fumbling with command options in shortcuts... but 
that's really lame. Can I ask somebody familiar with IDLE to look at this? 

Thank you once more.

-- ddbug
-- 
https://mail.python.org/mailman/listinfo/python-list