|
in reply to Re: What sets Perl back
in thread What sets Perl back
I'm the same, using CPAN drives me nuts. First it insists on downloading an ancient version of nmake.exe from the net, when there is already a much more up to date version on my system, simple because I keep my executables where they are supposed to be (eg. the compilers bin directory in this case), not where cpan thinks it belongs. It's in my path. Just use it already.
But before we get to that, it insists on downloading some damn index from cpan that takes forever. I wouldn't mind, but the next time I use it, it then wants to verify if it's copy of this mysterious dratted index is up to date. which takes longer than downloading it did, and it never is, so it goes ahead and downloads it again anyway.
Then, if the compiliation fails, which always seems to on Win32, I've no idea what it has succeded in doing and what not, because it hides all the output from me.
Like you, I prefer to download the tarballs (or sometimes just the .pms for simple one-file perl-only modules), but the dependancies are a pain. Maybe we should write a script that just builds a list of dependancies by querying cpan?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
|
Re^3: What sets Perl back
by szbalint (Friar) on Dec 11, 2005 at 13:41 UTC
|
Yeah, I hear your pain, some of it is shared by humble myself too.
What I'd love to see is some level of integration into package management, like in my case, apt-get.
Another annoyance is that CPAN:: doesn't have any uninstall/remove capabilities, or at least not something trivial like install <module> is.
CPAN is a great resource, but making it more accessible would help a lot in code reuse. There are some modules which depend on half of CPAN and installing such monsters are hard and annoying. When the compilation fails somewhere I have to figure which debian packages to install, then retry. Not really userfriendly.
| [reply]
[d/l] |
Re^3: What sets Perl back
by demerphq (Chancellor) on Dec 11, 2005 at 16:07 UTC
|
First it insists on downloading an ancient version of nmake.exe from the net, when there is already a much more up to date version on my system, simple because I keep my executables where they are supposed to be (eg. the compilers bin directory in this case), not where cpan thinks it belongs. It's in my path. Just use it already.
Thats very strange. I've never observed CPAN do anything like that, either with hand built perls or with AS builds. When I config CPAN it finds the correct nmake in my path, and uses it thereafter. I've never seen CPAN download nmake.exe, ever.
Then, if the compiliation fails, which always seems to on Win32, I've no idea what it has succeded in doing and what not, because it hides all the output from me.
Again thats a strange description when I see a failed build I see all the gory details, unless its a make test failure, in which case it isn't CPAN in the way, but Test::Harness, which usually means you need to look NAME and then nmake test TEST_VERBOSE=1 to see whats failed.
---
$world=~s/war/peace/g
| [reply]
[d/l]
[select] |
|
|
Maybe the nmake thing was just one particular package I tried to use CPAN.pm for that did that (Pugs?). I haven't attempted to use for so long that I don't remember for sure. I've had trouble using it on every build I've ever installed.
Do you get this lot every time you run it?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
|
|
Ok, a package downloading it makes sense. CPAN doing it doesn't (to me anyway). And yeah I get all that crap when i start up too. But my experience is that cygwin+VC+perl makes for a fully capable CPAN framework. Although the index stuff is a little annoying I actually use a local mirror that is synched throughout the day so usuall don't have to re-download it.
---
$world=~s/war/peace/g
| [reply] |
Re^3: What sets Perl back
by gunzip (Pilgrim) on Dec 11, 2005 at 14:51 UTC
|
Add to this the unfathomable inability of CPAN.pm to download the MIRRORED.BY file. I've known CPAN.pm go through almost my whole list of mirrors failing to download the damned thing and when I've checked the URL the file is right there on the FTP server where it ought to be. Why is this allowed to go on? I can't be the only one going through this nonesense. As I said at the start this kind of thing is setting back the adoption of Perl. Developers who are not fully committed to doing whatever it takes to get Perl modules installed are going to eventually use something else. Perl will only have itself to blame if it becomes marginalised. | [reply] |
|
|
I have that problem with every new MacOS install, but the problem isn't with Perl, or even the OS ... it's my firewall. CPAN.pm tries to use Net::FTP, which MacOS has installed -- but it doesn't have a libnet.cfg file, and I'm behind a firewall which requires me to use passive FTP.
In cases like this, it has nothing to do with the commitment of Perl devlopers, or the OS, or anyone else, but a knowledge of what my environment is. Every environment is different, and it is impossible for the developers to plan for every last possible permutation of configuration variables. They can get it so that things work most of the time, but once in a while, you actually have to look at the README files, and/or understand what the error messages are.
I personally find that you can often get help with problems by asking for it -- if you present it as a general bitch about the community, you are much less likely to get the problem that you're having resolved. If you actually want to get the problem fixed, I would assume that you would phrase it slightly differently than just general complaining. It might feel good to vent, but I find it normally feels even better to get it fixed, and behind you.
| [reply] |
|
|
I don't think it's a matter of simply getting it fixed. That's why I've phrased it this way. There is a danger that developers who don't want the hassle of compiler error messages and working out the internals of CPAN.pm will simply opt for something else and Perl may become marginalised due to its poor packaging.
| [reply] |
|
|
