July 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: New package system design draft 25 years, 4 months

Jan Vroonhof

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > It would be trivial enough to generally manage the `use-package' > clauses via a user interface. Aha. OK. So the package system would still do what I want, but simply at a higher level? i.e. there is a list of packages to 'use' somewhere that is typically managed by the package installation interface? Jan

1 participants
0 comments

Re: New package system design draft 25 years, 4 months

Didier Verna

Pete Ware <ware(a)cis.ohio-state.edu> writes: > Can one share package directories across machines and architectures > (cf. etc/) That's a good point. Perhaps the most important argument against having all files related to a package under a single directory. There's already a problem with the lib-src subdir, and will be another one when we start having packages with C modules in them. It would really be a pity not to fix this problem in the Great Package Overhaul. The fact is that most of the packages subdir already exist in the GNU Coding Standards. - etc, info, man exist. - lisp should go under .../share - lib-src actually belongs to libexec. - lib could then be used for C modules. So I think instead of having a single directory for a particular package, we could replicate this hierarchy under all needed standard directories, with the same naming policy. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

2 participants
1 comments

Re: New package system design draft 25 years, 4 months

Pete Ware

Michael Sperber [Mr. Preprocessor] <sperber(a)informatik.uni-tuebingen.de> writes: > > Jan> When exactly are the packages autoloads read? > > Upon `use-package.' > > Jan> What happens to packages > Jan> that are never '(use-package ..)'ed? > > Nothing happens to them, nothing happens with them. > > Jan> Or more specifically: How do the major/minor modes, menu entries > Jan> and user commands implemented by packages get advertised? > > Via `use-package.' There's no way around that if you want > multiple-version coexistence. Hmmm. I appreciate being able to choose multiple versions and the performance gain by not searching all the packages. Isn't Emacs starting up with a bunch of autoloads something we are pretty used to? Can one share package directories across machines and architectures (cf. etc/) --pete

1 participants
0 comments

Re: New package system design draft 25 years, 4 months

Michael Sperber

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Or more specifically: How do the major/minor modes, menu entries Jan> and user commands implemented by packages get advertised? >> >> Via `use-package.' There's no way around that if you want >> multiple-version coexistence. Jan> Aren't you throwing out the baby with the bath water then. One my Jan> reasons for using XEmacs was that there are lot more "third party" Jan> tools that you could use. Look how much simpler the installation Jan> instruction for X-symbol and Reftex have become with the current Jan> package system. "Untar, restart, M-x reftex-mode RET". It would be trivial enough to generally manage the `use-package' clauses via a user interface. We don't really have a choice. It was a mistake to make things implicit which should be explicit. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: New package system design draft 25 years, 4 months

Jan Vroonhof

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > Jan> I would love to see (for the purposes of the install tool) the debian > Jan> dpkg-style weaker dependencies. Also I would dearly love a list of > Jan> features provided (or at least major and minor modes). > > Could you elaborate? I know nothing about dpkg. The debian package system has progressively weaker dependencies that are something like this depends: Technically required to run (typically needed libraries). recommends: Normal operation typically requires this to be intalled too. suggest: This might be useful if you are using this packages. Only "depends" is enforced by the low level package system. Recommends and suggests are used by the package installer UI. When you select a package you are shown all three dependencies with the Depends and Recommends default to selected. This makes it a lot easier to find your way around the packages. In our case for instance auctex would "suggest" reftex. Jan > Jan> Or more specifically: How do the major/minor modes, menu entries > Jan> and user commands implemented by packages get advertised? > > Via `use-package.' There's no way around that if you want > multiple-version coexistence. Aren't you throwing out the baby with the bath water then. One my reasons for using XEmacs was that there are lot more "third party" tools that you could use. Look how much simpler the installation instruction for X-symbol and Reftex have become with the current package system. "Untar, restart, M-x reftex-mode RET". How would something like "(auto-compression-mode 1)" work without it being autoloaded etc. This aspect worries me. I know the current scanning takes time but it _is_ mighty convenient. Jan

1 participants
0 comments

Re: New package system design draft 25 years, 4 months

Michael Sperber

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Also I would dearly love a list of Jan> features provided (or at least major and minor modes). That makes sense. I'll keep it in mind. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: New package system design draft 25 years, 4 months

Michael Sperber

>>>>> "dv" == Didier Verna <verna(a)inf.enst.fr> writes: dv> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> I still don't understand. What's the meaning of "to require another >> package (not only one feature of this package)" operationally? dv> Well, my idea was to require at once all the features a package can dv> provide, in the case several of them would need to be require'd dv> explicitely. I'm sure packages for which this makes sense already have a "super-feature" ('w3 probably is one) which, when require'd, requires the other ones or signs them up for autoload. I don't think it makes sense to do special API provision for this case. However, it would make plenty of sense to establish naming conventions for them. The mental step from "vc" to (require 'vc-hooks) is a big one. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: New package system design draft 25 years, 4 months

Jan Vroonhof

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > - a name (a symbol) > - a description > - a version (a string "<major>.<minor>") Are <major> and <minor> supposed to be numbers? > - a list of package specifications (see below) which must be satisfied > for the package to be able to compile > - a list of package specifications (see below) which must be satisfied > for the package to run I would love to see (for the purposes of the install tool) the debian dpkg-style weaker dependencies. Also I would dearly love a list of features provided (or at least major and minor modes). > (use-package <package-specification>) > > This indicates a preference for a package matching the specification > to XEmacs. This means that, in the future, no other packages with the > same name may be used in the running XEmacs. It also has the > side-effect of making the package's autoloads available. When exactly are the packages autoloads read? What happens to packages that are never '(use-package ..)'ed? Or more specifically: How do the major/minor modes, menu entries and user commands implemented by packages get advertised? > Nothing related to packages shows up in the relevant ...-path and > ...-directory-list variables. (I.e., package lisp subdirectories do > not end up in `load-path.) However, the relevant functions which used > to search in them still go through the package directories as a last > resort. Thus 'load-path''s standard value is "nil"? Per is going to love that. Jan

1 participants
0 comments

Re: New package system design draft 25 years, 4 months

Didier Verna

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > I still don't understand. What's the meaning of "to require another > package (not only one feature of this package)" operationally? Well, my idea was to require at once all the features a package can provide, in the case several of them would need to be require'd explicitely. However, I admit I have no pertinent example of this right now. In a similar vein, you might let the FEATURE argument in `require-package-feature' to be either a symbol, or a list of symbols. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: New package system design draft 25 years, 4 months

Michael Sperber

>>>>> "dv" == Didier Verna <verna(a)inf.enst.fr> writes: dv> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: dv> But is it possible for a package to require dv> another one ? Like, in gnus you would have (require-package w3 <spec). >> >> I don't understand this. What's "<spec)"? dv> Typo. I meant suppose that a package requires another package (not dv> only one feature of this package) with a particular specification, hence it dv> would be nice to have something similar to you require-package-feature, but dv> for the whole package itself: I still don't understand. What's the meaning of "to require another package (not only one feature of this package)" operationally? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta July 1999