On Wed, Oct 22, 2008 at 3:13 AM, Gabor Szabo <[EMAIL PROTECTED]> wrote: > 1) I see that many of the sub packages are actually within CPAN.pm. > I thought I'll move them into separate .pm file but looking again > I am not sure all of them should be moved. > CPAN::Shell is big so I am moving it right now but there are several > very small ones that might just create unnecessary overhead > in maintenance if we put them in separate files. What do you think?
There are a lot of global variables set in CPAN.pm. You'll need to be very careful breaking things out. Personally, I'd like to figure out how to eliminate the globals first as that will make refactoring much easier. > 2) As I understand the printing is done by CPAN::Shell::myprint() > [snip] > I could parse the strings and try to figure out what kind of output I get > but it will be much easier if there different printing functions > were called for different data types. > Then I could implement those separate functions and know what kind > of data to expect. Do you need to do this via print and formats? Why not access the data structures directly? > 3) First I thought the CPAN GUI will run the CPAN client in the current perl > but now I have another idea. I am not sure yet about. > Padre has lots of dependencies and it also requires a threaded perl. > Users might install it in a perl that is not their production perl. > I could see the same with the CPAN GUI client. People might want to have it > but not installed in the perl they are using. > > So I thought CPAN.pm should have remote capabilities just as the -d debugger > has. > > What do you think? Ambitious. I'd try to get it working with the current perl first. -- David
