Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use git submodules for dependencies where possible #398

Closed
Keno opened this issue Feb 19, 2012 · 14 comments
Closed

Use git submodules for dependencies where possible #398

Keno opened this issue Feb 19, 2012 · 14 comments
Assignees
Labels
building Build system, or building Julia or its dependencies

Comments

@Keno
Copy link
Member

Keno commented Feb 19, 2012

I think it might be a good idea to use git submodules to handle dependencies where possible. Not only would that avoid having to use wget/curl, but it would also enable working directly on the dependencies and pushing those changes upstream without much difficulty.

@StefanKarpinski
Copy link
Member

This is an excellent idea that I've been pondering for a while. I had been reluctant because the last time I used git submodules it was not a very well-developed feature. Admittedly that was like five years ago or some such.

@ghost ghost assigned StefanKarpinski Feb 19, 2012
@StefanKarpinski
Copy link
Member

Perhaps we should also make cloned GitHub repos under JuliaLang for the dependencies that aren't already on GitHub? That way there's a consistent way to get everything and even a place to maintain our own patches (although that's a bit more questionable).

@Keno
Copy link
Member Author

Keno commented Feb 19, 2012

I think that would be a good idea.

@Keno
Copy link
Member Author

Keno commented Feb 19, 2012

Also, some of the dependency projects have SVN repositories, so it shouldn't be a problem to use the git svn bridge (this would require to set up a repo that serves as a bridge. LLVM already has it at http://llvm.org/git/llvm.git (see http://llvm.org/docs/GettingStarted.html#git_mirror).

@ViralBShah
Copy link
Member

Isn't there some kind of a github restriction on number of repositories for an organization for free usage? Of course, the github fee is quite reasonable, and we can just start paying that.

@Keno
Copy link
Member Author

Keno commented Feb 20, 2012

I'm fairly certain that github has unlimited public repositories

@ViralBShah
Copy link
Member

I think our current build process is working fine, largely. Not sure if this is necessary. Should we close this?

@Keno
Copy link
Member Author

Keno commented May 1, 2012

This is more a way of simplifying development, by allowing us to try out upstream branches and/or directly commit changes, rather than a build simplification.

@StefanKarpinski
Copy link
Member

I'm designing a package system that uses git submodules and I think it would make everything better if even our code dependencies were installed and managed this way (except LLVM, which is really part of Julia). So no, don't close it.

On May 1, 2012, at 12:47 PM, Keno Fischerreply@reply.github.com wrote:

This is more a way of simplifying development, by allowing us to try out upstream branches and/or directly commit changes, rather than a build simplification.


Reply to this email directly or view it on GitHub:
#398 (comment)

@ViralBShah
Copy link
Member

With the recent SuiteSparse website downtime, there is perhaps more reason to use submodules. I say we wait for Stefan's package stuff to be ready.

@StefanKarpinski
Copy link
Member

I'm pretty close. I say we make things like sparse matrices some of the first test packages. They might be installed by default, but they should still be bundled up like packages.

@ViralBShah
Copy link
Member

arpack, sparse, gmp, and glpk are good first candidates.

-viral

On 29-May-2012, at 9:25 AM, Stefan Karpinski wrote:

I'm pretty close. I say we make things like sparse matrices some of the first test packages. They might be installed by default, but they should still be bundled up like packages.


Reply to this email directly or view it on GitHub:
#398 (comment)

@ViralBShah
Copy link
Member

What do we do about this issue? I have often thought of taking all of deps and converting it into a git repository. Instead of downloading various packages, one would just clone this repository and get all the dependencies. Keeping it separate also makes it possible for other projects to use it.

@ViralBShah
Copy link
Member

Perhaps this is no longer as important, given that we are rapidly moving stuff into packages.

StefanKarpinski pushed a commit that referenced this issue Feb 8, 2018
cmcaine pushed a commit to cmcaine/julia that referenced this issue Nov 11, 2022
The `.appends/.github/labels.yml` file contains all the labels that are currently used in this repo. The `.github/labels.yml` file will contain the full list of labels that this repo can use, which will be a combination of the `.appends/.github/labels.yml` file and a centrally-managed `labels.yml` file. We'll automatically sync any changes, which allows us to guarantee that all the track repositories will have a pre-determined set of labels, augmented with any custom labels defined in the `.appends/.github/labels.yml` file.
dkarrasch pushed a commit that referenced this issue Jul 22, 2023
Stdlib: SparseArrays
URL: https://github.com/JuliaSparse/SparseArrays.jl.git
Stdlib branch: main
Julia branch: master
Old commit: b4b0e72
New commit: 99c99b4
Julia version: 1.11.0-DEV
SparseArrays version: 1.10.0 (Does not match)
Bump invoked by: @dkarrasch
Powered by:
[BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl)

Diff:
JuliaSparse/SparseArrays.jl@b4b0e72...99c99b4

```
$ git log --oneline b4b0e72..99c99b4
99c99b4 Specialize 3-arg `dot` for sparse self-adjoint matrices (#398)
cb10c1e use unwrapping mechanism for triangular matrices (#396)
b3872c8 added warning for iterating while mutating a sparse matrix (#415)
f8f0f40 bring coverage of fixed SparseMatrixCSC to 100% (#392)
0eb9c04 fix typos (#414)
```

Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
KristofferC pushed a commit that referenced this issue Jul 24, 2023
Stdlib: SparseArrays
URL: https://github.com/JuliaSparse/SparseArrays.jl.git
Stdlib branch: main
Julia branch: master
Old commit: b4b0e72
New commit: 99c99b4
Julia version: 1.11.0-DEV
SparseArrays version: 1.10.0 (Does not match)
Bump invoked by: @dkarrasch
Powered by:
[BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl)

Diff:
JuliaSparse/SparseArrays.jl@b4b0e72...99c99b4

```
$ git log --oneline b4b0e72..99c99b4
99c99b4 Specialize 3-arg `dot` for sparse self-adjoint matrices (#398)
cb10c1e use unwrapping mechanism for triangular matrices (#396)
b3872c8 added warning for iterating while mutating a sparse matrix (#415)
f8f0f40 bring coverage of fixed SparseMatrixCSC to 100% (#392)
0eb9c04 fix typos (#414)
```

Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
(cherry picked from commit 6691a75)
Keno pushed a commit that referenced this issue Oct 9, 2023
While I'm not aware of any problems caused by the former setting,
when frames are being created for the purpose of analysis rather than
execution it seems worth being able to control the evaluation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
building Build system, or building Julia or its dependencies
Projects
None yet
Development

No branches or pull requests

3 participants