From: Andrew P. <and...@gm...> - 2011-03-11 23:46:26
|
In the MinGW Shell: $ mingw-get update $ mingw-get install python $ mingw-get install git $ mingw-get install vi C:\MinGW\bin\mingw-get.exe: *** ERROR *** python: unknown package C:\MinGW\bin\mingw-get.exe: *** ERROR *** git: unknown package C:\MinGW\bin\mingw-get.exe: *** ERROR *** vi: unknown package None of these seem to be accessible via mingw-get. Does MinGW not have ports for these? I know binaries are available, but I'd like to install everything I can with mingw-get. Cheers, Andrew Pennebaker www.yellosoft.us |
From: LRN <lr...@gm...> - 2011-03-12 03:25:56
|
On 12.03.2011 2:45, Andrew Pennebaker wrote: > In the MinGW Shell: > > $ mingw-get update > $ mingw-get install python > $ mingw-get install git > $ mingw-get install vi > > C:\MinGW\bin\mingw-get.exe: *** ERROR *** python: unknown package > C:\MinGW\bin\mingw-get.exe: *** ERROR *** git: unknown package > C:\MinGW\bin\mingw-get.exe: *** ERROR *** vi: unknown package > > None of these seem to be accessible via mingw-get. > > Does MinGW not have ports for these? I know binaries are available, but I'd > like to install everything I can with mingw-get. > > Cheers, > > Andrew Pennebaker > www.yellosoft.us > mingw-get is very primitive, and its only purpose is to install mingw/msys and their dependencies. It was not meant to be used to as a generic package manager for NT OSes. Because of that the developers want to make the set of packages available via mingw-get as small as possible and do not want to pull any extra dependencies. Python is not really related to MinGW or Msys and thus is not available (obviously, you can get official CPython for Windows). Also, CPython at the moment can't be built in Msys (there are patches to allow this, haven't been accepted into the trunk yet). Also, msys-python (a Python that links against msys-1.0.dll) simply does not exist. Git might be available eventually (if i have any say in this). Until then you'd have to take it from msysgit and combine it with msys manually (by installing msys on top of msysgit and then merging together msys /etc/profile script with a backed up version of it from msysgit). There's no vi, but there is vim. mingw32-vim, i think? |
From: Charles W. <cwi...@us...> - 2011-03-12 05:57:21
|
On 3/11/2011 10:18 PM, LRN wrote: > On 12.03.2011 2:45, Andrew Pennebaker wrote: >> C:\MinGW\bin\mingw-get.exe: *** ERROR *** python: unknown package >> C:\MinGW\bin\mingw-get.exe: *** ERROR *** git: unknown package >> C:\MinGW\bin\mingw-get.exe: *** ERROR *** vi: unknown package > > Python is not really related to MinGW or Msys and thus is not available > (obviously, you can get official CPython for Windows). Python is a useful scripting tool, but (a) the purpose of MSys is /not/ to provide a general purpose unix environment on Windows. That's cygwin -- and we don't aim to supplant cygwin. (b) the contents of MSys are selected to enable running configure scripts, and basic maintenance and compilation of win32 (that is, mingw32) ports of open source packages. To meet that goal, we provide autoconf/automake/libtool...which, in turn, requires a port of perl. So, we provide msys-perl, but not msys-python. > Git might be available eventually (if i have any say in this). Until > then you'd have to take it from msysgit and combine it with msys > manually (by installing msys on top of msysgit and then merging together > msys /etc/profile script with a backed up version of it from msysgit). Yes, getting a working git integrated into a MinGW/MSys installation is a bit tricky right now, but I agree that we ought to provide a port. Once you and I (well, mostly you, LRN, so far) finish the ongoing perl updates, I plan to work on a true msys port of git (fyi: the 'msysgit' version of git is actually a *win32* port, bundled with an msys environment) > There's no vi, but there is vim. mingw32-vim, i think? We provide a port of vim, but it is an msys port: mingw-get install msys-vim As LRN points out, you're certainly free to install -- via their own installers -- the regular win32 ports of any tool you like (such as CPython, etc) and use them from within your MSys environment. -- Chuck |
From: LRN <lr...@gm...> - 2011-03-12 06:53:34
|
On 12.03.2011 8:56, Charles Wilson wrote: > On 3/11/2011 10:18 PM, LRN wrote: > >> Git might be available eventually (if i have any say in this). Until >> then you'd have to take it from msysgit and combine it with msys >> manually (by installing msys on top of msysgit and then merging together >> msys /etc/profile script with a backed up version of it from msysgit). > Yes, getting a working git integrated into a MinGW/MSys installation is > a bit tricky right now, but I agree that we ought to provide a port. > Once you and I (well, mostly you, LRN, so far) finish the ongoing perl > updates, I plan to work on a true msys port of git (fyi: the 'msysgit' > version of git is actually a *win32* port, bundled with an msys environment) I know. It was a shocking thing to discover. Though, if msysgit (which is really a mingw-git) works as intended without using msys - why not use it? Msys is not the goal, working applications are. So if it works - i'm ok with it. As long as there are no downsides (will have to look into this and ask around msysgit ML). |
From: Charles W. <cwi...@us...> - 2011-03-12 17:11:42
|
On 3/12/2011 1:52 AM, LRN wrote: > On 12.03.2011 8:56, Charles Wilson wrote: >> (fyi: the 'msysgit' >> version of git is actually a *win32* port, bundled with an msys environment) > I know. It was a shocking thing to discover. > Though, if msysgit (which is really a mingw-git) works as intended > without using msys - why not use it? I suspect -- but do not know for certain -- that an msys port will be a better approach, mainly because upstream git is, by and large, a unix-oriented tool. AFAIK, msysgit's win32 patches have not been accepted upstream -- but we DO know that the cygwin port is well supported. In fact, the maintainer of cygwin's official package of git applies some patches because: > When compiled out of the box, the upstream git maintainers cater to > older cygwin releases, and intentionally disable certain features that > have been reported on their mailing list, even though they work with > the latest cygwin. Therefore, this build turns those features back > on. that is, upstream git focus on working with old cygwin -- which means that (unlike, for instance, openssh) we can expect stock upstream git to play nicely with MSys. (Sadly, as cygwin gains or improves support more features, openssh is updated to use them, or to remove old workarounds. With each new openssh release, I have to do code archeology and put those workarouds back in, to allow openssh to operate with MSys's more primitive featureset) Further, git has several library dependencies for optional functionality, and by and large porting random-package-X to MSys is a lot easier than porting it to 'native' win32 (openssh's counterexample notwithstanding). So, we can more easily get a relatively-full-featured git by going the MSys route, than by sticking with a more-or-less stripped-down mingw32 version of git. I'm also thinking about automation. If we port git -- either borrowing msysgit's mingw version, or our own msys port (*) and eventually transition our sourceforge.net CVS repo to the new format, we have several automation tools such as the Makefiles associated with building mingw-get xml manifests that would need to be ported. Making these all work and accept win32 paths will be...awkward, so I'd prefer to stick with unixish formulations wherever possible. (*) or some other modern DVCS tool; it's just that git is under discussion in this thread That's just my gut feeling, but... -- Chuck |
From: Earnie <ea...@us...> - 2011-03-14 12:24:56
|
Charles Wilson wrote: > On 3/12/2011 1:52 AM, LRN wrote: >> On 12.03.2011 8:56, Charles Wilson wrote: >>> (fyi: the 'msysgit' >>> version of git is actually a *win32* port, bundled with an msys environment) > >> I know. It was a shocking thing to discover. >> Though, if msysgit (which is really a mingw-git) works as intended >> without using msys - why not use it? > > I suspect -- but do not know for certain -- that an msys port will be a > better approach, mainly because upstream git is, by and large, a > unix-oriented tool. AFAIK, msysgit's win32 patches have not been > accepted upstream -- but we DO know that the cygwin port is well > supported. I suspect an MSYS build of git client tools would be the better solution as well. From what I've seen the windows port of git is treated as a parallel maintenance fork. -- Earnie -- http://www.for-my-kids.com |
From: Ralf W. <Ral...@gm...> - 2011-03-12 08:28:35
|
Hi Charles, * Charles Wilson wrote on Sat, Mar 12, 2011 at 06:56:39AM CET: > > Python is a useful scripting tool, but (a) the purpose of MSys is /not/ > to provide a general purpose unix environment on Windows. That's cygwin > -- and we don't aim to supplant cygwin. (b) the contents of MSys are > selected to enable running configure scripts, and basic maintenance and > compilation of win32 (that is, mingw32) ports of open source packages. > To meet that goal, we provide autoconf/automake/libtool...which, in > turn, requires a port of perl. > > So, we provide msys-perl, but not msys-python. That is an interesting argumentation. IIUC Autotools have been avoiding python also because it is less portably available in practice (e.g., on MinGW and some older proprietary systems[1]). Of course it's not only that, but also the fact that using both perl and python in a project (for purposes other than interfacing to them) seems like a suboptimal design decision. But still, the recursive argumentation of either side, logical as it may be when looked at in isolation, taken together might prevent things to happen that some might regard as progress. ;-) Just a thought. Cheers, Ralf [1] JFTR, I didn't mean to say python was less portable. |