Re: [Python-Dev] PEP: Collecting information about git

[André Freitas]

Regarding Git tools for Windows, GitHub Desktop and Sourcetree are actually
very good with nice features.

A Qui, 17/09/2015, 04:12, Nikolaus Rath  escreveu:

> On Sep 16 2015, Terry Reedy  wrote:
> > On 9/16/2015 5:20 AM, Oleg Broytman wrote:
> >
> >> On Tue, Sep 15, 2015 at 07:44:28PM +, Augie Fackler <
> r...@durin42.com> wrote:
> >
> >>> There are a lot of reasons to prefer one tool over another. Common
> ones are
> >>> familiarity, simplicity, and power.
> >>
> >> Add here documentation, speed, availability of extensions and
> >> 3rd-party tools, hosting options (both locally installable and web
> >> services).
> >
> > For me, the killer 3rd party tool in favor of hg is TortoiseHg, which
> > I use on Windows. As far as I know (I did check a bit), there is no
> > equivalent for git on Windows.
>
> .. or elsewhere. Tortoisehg rocks.
>
> Best,
> -Nikolaus
>
> --
> GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
> Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
>
>  »Time flies like an arrow, fruit flies like a Banana.«
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/p.andrefreitas%40gmail.com
>
-- 
André Freitas
andrefreitas.pt
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Collecting information about git

[Tim Golden]

On 17/09/2015 02:59, Terry Reedy wrote:
> On 9/16/2015 5:20 AM, Oleg Broytman wrote:
> 
>> On Tue, Sep 15, 2015 at 07:44:28PM +, Augie Fackler
>>  wrote:
> 
>>> There are a lot of reasons to prefer one tool over another. Common
>>> ones are
>>> familiarity, simplicity, and power.
>>
>> Add here documentation, speed, availability of extensions and
>> 3rd-party tools, hosting options (both locally installable and web
>> services).
> 
> For me, the killer 3rd party tool in favor of hg is TortoiseHg, which I
> use on Windows. As far as I know (I did check a bit), there is no
> equivalent for git on Windows.  For me, the evaluation should be between
> hg+TortoiseHG versus git+???.

There certainly is (and with the obvious name!):

https://tortoisegit.org/

I use it every day

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python windows installation inconsistent use of registry keys

[Barry Scott]

> On 15 Sep 2015, at 18:39, Barry Scott  wrote:
> 
> I am used to looking in 
> HKLM:\SOFTWARE\Python\PythonCore\%(py_maj)d.%(py_min)d\InstallPath
> to find out where python is installed so that my installation kit can add 
> itself to site-packages.
> 
> I just found that the registry key used for 32 bit python 3.5 on windows 
> changed to be '3.5-32',
> which I can change my installer to cope with.
> 
> However the key for the 64bit install is ‘3.5’ but not '3.5-64'.
> 
> Why was this changed and why not consistently between 32 and 64 bit versions?
> 

Raised as bug http://bugs.python.org/issue25148

> Barry
> PyCXX, PySVN maintainer
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/barry%40barrys-emacs.org

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Proposing the deprecation of the pyvenv script

[Brett Cannon]

I opened http://bugs.python.org/issue25154 for this idea and below is
what I put in the issue as to why I think we should deprecate the
pyvenv script in favour of `python3 -m venv`.


I propose that the pyvenv script be deprecated in Python 3.5.1 and
removed in Python 3.8. The reason for this proposal is because it is
non-obvious what version of Python a pyvenv command is tied to (heck,
it isn't necessarily obvious that it's Python 3). There would be no
loss in functionality since the exact same functionality is available
through `python3 -m venv`. This is a backwards-compatibility change,
hence the deprecation, but changing various shell scripts and such
should be trivial thanks to the -m flag. This would also help promote
the use of -m, especially for any projects that rely on being tied to
a specific installed interpreter.

As pointed out in issue #25152 ,
virtualenv provides a -p flag to specify what version of Python should
be used to create a virtual environment:
https://virtualenv.pypa.io/en/latest/reference.html#virtualenv-command.
The pyvenv script and venv package provide no such mechanism since it
is included in the stdlib, which makes sense since improvements will
be tied to the stdlib of the Python interpreter being used while
virtualenv is a standalone project/app.

Some may argue that worrying about this is unnecessary, but we are
already ending up with OSs that come with multiple versions of Python
pre-installed, let alone when people install their own versions of
Python on top of the system installation. For instance, OS X Yosemite
comes with Python 2.6 and 2.7, and then if you install the latest
version of Python independently you end up with 3 installations. If
they all happened to have a pyvenv script you wouldn't easily know
which Python interpreter the pyvenv command was going to use for the
virtual environment.

Since the pyvenv script is just a script, the deprecation will be in
the form of a message printed to sys.stderr in the
Tools/scripts/pyvenv
 file
mentioning that the deprecation and that people should switch to
`python3 -m venv` instead. The long deprecation cycle is for those who
have pyvenv provided by their OS and only upgrade Python every few
years, and thus run the risk of missing the deprecation warning. As
for the deprecation in Python 3.5.1, that's to get the warning out
immediately and to minimize people missing the deprecation prior to
the removal.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Collecting information about git

[Ryan Gonzalez]

*cough* Google *cough*

http://stackoverflow.com/questions/5911774/git-gui-like-hg-workbench-in-ms-windows

SourceTree looks quite similar.


On Thu, Sep 17, 2015 at 2:07 PM, Terry Reedy  wrote:

> On 9/17/2015 3:17 AM, André Freitas wrote:
>
>> Regarding Git tools for Windows, GitHub Desktop and Sourcetree are
>> actually very good with nice features.
>>
>
> Do you know if either have anything like TortoiseHg Workbench?
> https://tortoisehg.readthedocs.org/en/latest/workbench.html
> (screenshot at top)
>
> --
> Terry Jan Reedy
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>



-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing the deprecation of the pyvenv script

[Barry Warsaw]

On Sep 17, 2015, at 06:40 PM, Brett Cannon wrote:

>I propose that the pyvenv script be deprecated in Python 3.5.1 and
>removed in Python 3.8. The reason for this proposal is because it is
>non-obvious what version of Python a pyvenv command is tied to (heck,
>it isn't necessarily obvious that it's Python 3).

That's why in Debian/Ubuntu we include /usr/bin/pyvenv-X.Y for all supported
versions (currently 3.4 and 3.5 in Ubuntu 15.10), and then symlink
/usr/bin/pyvenv to the default one.  So I'm sympathetic to this proposal.

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Collecting information about git

[Terry Reedy]

On 9/17/2015 3:17 AM, André Freitas wrote:

Regarding Git tools for Windows, GitHub Desktop and Sourcetree are
actually very good with nice features.


Do you know if either have anything like TortoiseHg Workbench?
https://tortoisehg.readthedocs.org/en/latest/workbench.html
(screenshot at top)

--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Collecting information about git

[Terry Reedy]

On 9/17/2015 3:09 AM, Tim Golden wrote:

On 17/09/2015 02:59, Terry Reedy wrote:

On 9/16/2015 5:20 AM, Oleg Broytman wrote:


On Tue, Sep 15, 2015 at 07:44:28PM +, Augie Fackler
 wrote:



There are a lot of reasons to prefer one tool over another. Common
ones are
familiarity, simplicity, and power.


 Add here documentation, speed, availability of extensions and
3rd-party tools, hosting options (both locally installable and web
services).


For me, the killer 3rd party tool in favor of hg is TortoiseHg, which I
use on Windows. As far as I know (I did check a bit), there is no
equivalent for git on Windows.  For me, the evaluation should be between
hg+TortoiseHG versus git+???.


TortoiseHG includes the Workbench program, which to me is the superstar 
of the package and what I use daily for everything except a batch 
program to pull and update the multiple repositories (currently 3.6 and 
3.5, 3.4, and 2.7 shares).  Screenshot here

https://tortoisehg.readthedocs.org/en/latest/workbench.html

The main dag + (changeset + working directory) pane can have a tab for 
each branch repository. A sub-pane for the selected changeset or working 
directory lists the files changed. A sub-sub-pane shows a diff for the 
selected file.  So it is easy to check that all branch repositories are 
ready for a commit+merge. Once ready, committing to 2.7 and 3.4, merging 
to 3.5 and 3.6, and pushing takes less than a minute, thereby minimizing 
the change of losing a push race.



There certainly is (and with the obvious name!):

https://tortoisegit.org/


This works off of right-click context menus, as tortoisesvn did and 
tortoisehg can, but I looked at the screenshots and there is no 
workbench program.  So, for me, not equivalent at all.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com