You can replace Sake but RIO, Sunit extensions (if you find it)
So you are the lead on pharo and you have never used universes? Sorry
but using I cant find SUnitExtensions when the package is and has
always been called "SUnit-improved" as an excuse is is totally
ridiculous.
Are my answer satisfactory?
Now I have a question:
- do you use sake personnally?
- do you have positive experience?
- did you check the code? what is your feedback?
- is there tests?
- what do you think about task definition pros and cons?
I have no idea what you mean by this question.
This is all backwards. Your questions are all demonstrating the old
pharo code snobbery which really isn't relevant to the argument at all.
The whole point is to have a plan and a vision that people work
towards so that we end up with a coherent solution that does what we
and the community need. If something is not quite up to scratch then
you/me/anyone can join in and contribute to bring it up to speed. Code
snobs are welcome and helpful, if they contribute, rather than
compete. Rejecting things just because its a few tests short is simply
demonstrating a lack of interest in the overall concept. The
repositories are open and have always been open for you to contribute
to.
Let me outline the basics of the plan... I cant say whether these
things work in pharo or not.
0. Installer = for bootstrapping stuff anywhere including kernel
minimal gui-less images.
(gofer whatever that is, is not for kernel images, so you havent got
anything to fulfill this role)
If you were committed to not undermining the vision of "the DSM for
installing things", you would develop gofer as InstallerGofer
available via
Installer gofer
addPackage: 'PackageA';
latest;
quietly;
install.
Then you would have the same functionality, but you would be
contributing to the vision rather than setting up as competition from
the outset. You would also have additional benefits such as tools for
loading Gofer in all forks, see 0a below.
0a InstallerScripts for bootstrapping stuff with scripts that may
differ in different forks.
(ScriptLoader is a pharo only hack - so you haven't got anything to
fulfil this role either)
1. Monticello, Monticello Configurations, and PackageInfo = the same
in all forks, with all forks merged so that we can move MC forward
with Atomic loading and binary loading.
2. SUnit - same in all forks, with categorisation of tests, tagging as
to what works where.
3. LPF for bootstrapping and loading all of the above in all forks.
4. Sake (vision = minimal support for tasks with dependencies)
It doesnt matter if you dont like a single bytecode of the sake code,
the principle is "a package that gives the minimal support for make
like task graphs". If you happen to be a make/rake expert, then enter
the dialog and tell me what I am doing wrong, we could start again
from scratch if you like, I don't care. But please DONT compete for
the sake of it.
5. Sake/Packages (minimal gui-less package manager available in all
forks) defining what works where.
Again, if you don't like it, enter the dialog, and help, don't judge
from afar. Sake/Packages may not be perfect, but it has done better
than any other previous squeak dependency manager. The API is better
than Metacello, and its easier to use, and more versatile.
So, if you don't deliver something similar to this plan, AND deliver
it in all forks with equivalent functionality, then whatever you do
undermines this vison for everyone. This is exactly what has happened.
The vision has been undermined to the point of being hounded out of
existence. This email is the last death throe.
Hence the reason that I have been speaking up, repeatedly, the vision
is now pretty much completely undermined and almost gone, because it
is unsustainable. It is unsustainable because the leaders in our
community will not put any commitment to any visions other than their
own, and those for the most part only exist in their own heads. (i.e.
when you or andreas sit down to decide what bug to fix, or what you
are going to refactor there is no published detailed plan you are
working to)
You apparently loaded MC1.5 once, (whereas I have been using it for 2
years) and decided that it left lots of loose ends, the reason was
because you didnt unload the previous version of MC correctly. Your
version of collaborating with people on a plan, is to poke around in
squeaksource on your own, load a package that you think is the right
one, and when it doesnt work, simply tell everyone that you couldnt
find it.
Perhaps you are still in the dark ages, when we didnt have irc or a
package manager for squeak which understood dependencies. All you have
to do in an LPF image is Installer install: 'Packages'. and you would
be able to load SUnit-improved without a problem. We have had all of
this stuff working for all of the time I have been trying to persuade
you to use it.
Keith
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
