On Nov 5, 2013, at 08:46, Daniel J. Luke wrote:
I would say we should even go further, and get rid of all of the p5-* ports.
Instead, we should install perl5 as the latest stable perl, and include our
own 'cpanm' program (like how perlbrew has it's own) which would
On Nov 11, 2013, at 6:06 AM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 5, 2013, at 08:46, Daniel J. Luke wrote:
I would say we should even go further, and get rid of all of the p5-* ports.
Instead, we should install perl5 as the latest stable perl, and include our
own 'cpanm'
If a given CPAN module doesn't work then we could create a real Portfile
for it versus interfacing with CPAN. By default, I would assume, the
majority of modules should work. Tongue-in-cheek, I'd additionally say
tickets would be made for modules that don't just work.
I'm not sure we
On Nov 11, 2013, at 09:35, Daniel J. Luke wrote:
On Nov 11, 2013, at 6:06 AM, Ryan Schmidt wrote:
On Nov 5, 2013, at 08:46, Daniel J. Luke wrote:
I would say we should even go further, and get rid of all of the p5-* ports.
Instead, we should install perl5 as the latest stable perl, and
On Nov 11, 2013, at 11:32 AM, Ryan Schmidt ryandes...@macports.org wrote:
It would certainly be possible to have some local metadata that our cpanm
could consult to do any of the above, though.
This sounds like inventing a second language to do what we can already do in
portfiles.
I
I love the idea of a portfile override, but building from cpanm (cpanmp?)
most of the time.
—Mark
___
Mark E. Anderson e...@emer.net
On Mon, Nov 11, 2013 at 11:44 AM, Daniel J. Luke dl...@geeklair.net wrote:
On Nov 11, 2013, at 11:32 AM, Ryan Schmidt
On Nov 11, 2013, at 10:44, Daniel J. Luke wrote:
On Nov 11, 2013, at 11:32 AM, Ryan Schmidt wrote:
It would certainly be possible to have some local metadata that our cpanm
could consult to do any of the above, though.
This sounds like inventing a second language to do what we can
On Mon, Nov 11, 2013 at 12:01 PM, Ryan Schmidt ryandes...@macports.orgwrote:
I think we require base/ changes if only because there won't necessarily
be a portfile for each perl module yet there are going to be ports that
depend on some of these modules (so we would need a way to handle
On Nov 11, 2013, at 12:19 PM, Brandon Allbery allber...@gmail.com wrote:
Yes, base would need to be changed to accommodate this new feature. But I see
it as a minimal shim onto calling this other package manager.
Are we reinventing bsdpan?
yes :)
--
Daniel J. Luke
On Nov 11, 2013, at 12:01 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 11, 2013, at 10:44, Daniel J. Luke wrote:
On Nov 11, 2013, at 11:32 AM, Ryan Schmidt wrote:
It would certainly be possible to have some local metadata that our cpanm
could consult to do any of the above,
On Mon, Nov 11, 2013 at 12:26 PM, Ryan Schmidt ryandes...@macports.orgwrote:
On Nov 11, 2013, at 11:19, Brandon Allbery wrote:
Are we reinventing bsdpan?
I don’t know. What is bsdpan?
It's CPAN integration with BSD ports. Installing a port with a particular
naming pattern, if there is no
Hi all,
On Nov 3, 2013, at 1:31 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 3, 2013, at 15:06, Puneet Kishor wrote:
So, could one of kind and gentle folks tell in non-technical language the
incantation to make p5.18 default?
I suggest you wait until a perl5_18 variant is
On Nov 10, 2013, at 12:05 PM, Puneet Kishor punk.k...@gmail.com wrote:
Sadly, I need to use something later than perl 5.12. If I can't use Macports
perl, I would have to install a new version using Perlbrew (or some other
mechanism). Is there anything I can do for now to get with using the
Yeah, I'd apply that patch while we all figure out what to do. I'd be happy
to take on the Perl fixing work as Perl is my first language love. (Well
C/C++ I learned first, so I guess, my first scripting language love.
Technically, I learned BASIC on a TI/994A first, but the less said about
that
I would say we should even go further, and get rid of all of the p5-* ports.
Instead, we should install perl5 as the latest stable perl, and include our own
'cpanm' program (like how perlbrew has it's own) which would
download/build/(test)/install modules (probably into a DESTROOT to allow
Actually, I kinda like that idea. It will be a lot of work, though. But it
would keep me from having to mix CPAN and p5-* which I know is not
recommended, but I still do.
—Mark
___
Mark E. Anderson e...@emer.net
On Tue, Nov 5, 2013 at 9:46 AM, Daniel J. Luke
On Nov 3, 2013, at 4:42 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 3, 2013, at 15:38, Mark Anderson wrote:
Although we do need to come up with a better perl strategy. The current
workings drive me crazy.
I’m curious why that is. We use this strategy for PHP and Python as well
On Nov 3, 2013, at 5:44 PM, Clemens Lang c...@macports.org wrote:
To be honest, I don't know why we've ever diverged from this strategy.
We're in a habit of shipping the latest and greatest version of software
for most ports we have, sometimes even if breaks dependents (in which
case we try to
I'm with you there. 5.8 and 5.10 are long out of support. The Perl
community also strongly advises moving to the latest version as soon as it
is marked stable, that's why they make you do things like: use 5.018; to
get new features that can break old ones. Which is why I'm leaning more and
more
This is quite confusing
09:45:13 [lucknow.att.net] ~$ which perl
/opt/local/bin/perl
09:45:31 [lucknow.att.net] ~$ perl -v
This is perl 5, version 12, subversion 4 (v5.12.4) built for
darwin-thread-multi-2level
..
09:46:47 [lucknow.att.net] ~$ sudo port install perl5
On Nov 3, 2013, at 12:04, Mr. Puneet Kishor wrote:
This is quite confusing
09:45:13 [lucknow.att.net] ~$ which perl
/opt/local/bin/perl
09:45:31 [lucknow.att.net] ~$ perl -v
This is perl 5, version 12, subversion 4 (v5.12.4) built for
darwin-thread-multi-2level
..
So
On Sun, Nov 3, 2013 at 3:25 PM, Ryan Schmidt ryandes...@macports.orgwrote:
Observe with “port variants perl5” that it does not have a variant called
“perl5_18”. We should add one.
Actually, we shouldn't. We should remove the perl5 port hack and use port
select instead.
The good news is,
On Nov 3, 2013, at 14:37, Brandon Allbery allber...@gmail.com wrote:
On Sun, Nov 3, 2013 at 3:25 PM, Ryan Schmidt ryandes...@macports.org wrote:
Observe with “port variants perl5” that it does not have a variant called
“perl5_18”. We should add one.
Actually, we shouldn't. We should
I’m not sure that making more work is really something we want to do. Anything
perl5.18 should have a strict dependency on perl5.18 until we get this
ridiculousness hammered out.
Last we discussed, it sounded like even perl_select was not an ultimate
solution.
On Nov 3, 2013, at 15:38, Ryan
On Sun, Nov 03, 2013 at 03:41:59PM -0500, Jeremy Lavergne wrote:
I’m not sure that making more work is really something we want to do.
Anything perl5.18 should have a strict dependency on perl5.18 until we
get this ridiculousness hammered out.
Last we discussed, it sounded like even
So, could one of kind and gentle folks tell in non-technical language the
incantation to make p5.18 default?
Many thanks in advance.
--
Puneet Kishor
Science and Data Policy, Creative Commons
On Nov 3, 2013, at 12:41 PM, Jeremy Lavergne jer...@lavergne.gotdns.org
wrote:
I’m not sure that
On Nov 3, 2013, at 15:06, Puneet Kishor wrote:
So, could one of kind and gentle folks tell in non-technical language the
incantation to make p5.18 default?
I suggest you wait until a perl5_18 variant is added to the perl5 port:
https://trac.macports.org/ticket/41160
Then, use that (using
I've added a patch. I had one when I did perl 5.18 which i meant to add to
the ticket, but forgot. Although we do need to come up with a better perl
strategy. The current workings drive me crazy.
—Mark
___
Mark E. Anderson e...@emer.net
On Sun, Nov 3, 2013 at 4:31 PM, Ryan
On Nov 3, 2013, at 14:41, Jeremy Lavergne wrote:
On Nov 3, 2013, at 15:38, Ryan Schmidt wrote:
Yes, “port select” is the ultimate goal, but since that’s a larger issue
that will take time to resolve, adding a variant to the perl5 port is the
simple quick fix.
I’m not sure that making
On Nov 3, 2013, at 15:38, Mark Anderson wrote:
Although we do need to come up with a better perl strategy. The current
workings drive me crazy.
I’m curious why that is. We use this strategy for PHP and Python as well and
IMHO it works very well there. Do those drive you crazy also, or is it
I’m not sure that making more work is really something we want to do.
Right. But I’m not sure what course of action you’re advocating with that
sentence.
Introducing another perl5 variant means that’s another set of ports and their
variants we need to clean up if we were to switch to
I'm all for doing what we need to do. I use a lot of perl, and I have
always tried to install the latest or close to latest. Back before we had
the perl5 port I had a perl script that read every port file and
essentially did this: s/perl5.8/perl5.12/ - so I'm a big fan of having the
latest
Hi,
On Sun, Nov 03, 2013 at 05:12:45PM -0500, Mark Anderson wrote:
I'm all for doing what we need to do. I use a lot of perl, and I have
always tried to install the latest or close to latest. Back before we
had the perl5 port I had a perl script that read every port file and
essentially did
Yeah, that's my gut feeling. Just supporting the latest and greatest Perl
would be fine by me. The accelerated releases of Perl have caused a bit of
an issue - We were stuck with 5.8 for quite some time before the delay of
perl6 started causing a resurgence in interest in developing the perl core.
On Sun, Nov 3, 2013 at 5:44 PM, Clemens Lang c...@macports.org wrote:
I'd advocate for keeping the subport magic, though – there *will* be a
perl 6 sooner or later, and not throwing away that might simplify this
transition a lot.
Not even the perl 6 folks intend that it will replace perl 5
On Nov 3, 2013, at 16:44, Clemens Lang wrote:
To be honest, I don't know why we've ever diverged from this strategy.
We're in a habit of shipping the latest and greatest version of software
for most ports we have, sometimes even if breaks dependents (in which
case we try to fix the
On Nov 3, 2013, at 16:44, Clemens Lang wrote:
To be honest, I don't know why we've ever diverged from this strategy.
We're in a habit of shipping the latest and greatest version of software
for most ports we have, sometimes even if breaks dependents (in which
case we try to fix the
On Sun, Nov 03, 2013 at 07:30:48PM -0600, Ryan Schmidt wrote:
I believe the reason is because perl is a programming language, and
programming languages are used by end users, not just by other ports.
I agree with that, but I still think we're pushing this to the extreme
here. I think the
I installed perl5.14 and then another package installed perl5.12 and made that
the default perl. I would like to switch the default perl version to 5.14. I
see that /opt/local/bin/perl is symlinked to perl5.12. Instead of manually
changing that, what is the macports-recommended way for changing
On Feb 10, 2012, at 14:32, Puneet Kishor wrote:
I installed perl5.14 and then another package installed perl5.12 and made
that the default perl. I would like to switch the default perl version to
5.14. I see that /opt/local/bin/perl is symlinked to perl5.12. Instead of
manually changing
40 matches
Mail list logo
