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

Autoloader #2194

Closed
brendo opened this Issue Sep 6, 2014 · 75 comments

Comments

Projects
None yet
7 participants
@brendo
Member

brendo commented Sep 6, 2014

I've recently pushed an autoload branch to Symphony and I'd like to throw it open to feedback, thoughts and testing.

What

Don't get super excited, as the commits show this is a the most basic of all autoloaders, a classmap. It was manually constructed by me after compiling all the require_once statements throughout Symphony. In addition this branch moves some of the global constants to actual class constants (in a backwards compatible way).

I want this in the next release (not 2.5.0), but 2.6.0. Depending on how testing goes, this may be able to be included in 2.5.1 as backwards compatibility (in my testing) is retained.

Why

The boilerplate for loading Symphony is a total mess, it's a string of constant creation and then a maze of require statements to get the application going. In 2.5.0, I merged some of @psychoticmeow work to simplify the index.php file (did you know you can override the Symphony loader? You aren't limited to administration or frontend anymore...) and now I'd like to tackle the mess of require statements.

@designermonkey has put in some legwork to get PSR-2 going, and eventually I'd like to see that roll out to PSR-0/PSR-1. I hope that by abstracting all of the autoloading now, we have greater flexibility in future to change the directory structure to mirror a modern codebase, with namespaces and the like.

I want Symphony to be testable. In one of my Symphony applications, I have a 116 case test suite that is automatically run on every commit. It has saved my ass countless times. I want this for the core. It's not smart to continue as we are, pushing code in and giving it a smoke test to see that things still work. If it wasn't for @michael-e's brilliant testing knack, we'd have terrible product full of bugs.

But

Autoloading masks one of the worst things in our codebase, Symphony's classes are highly coupled and it's very difficult to use (and test) them in isolation. Mocking parts of Symphony will be difficult and make testing a milestone in itself, but we have to start somewhere (lets not derail this ticket with that talk yet)

Some Notes/Questions

  • Using the classmap autoloader appears to make Symphony boot slower by about .0100s. The memory usage doubles, although the number of classes loaded for me was reduced by about 14%. Any ideas on how to regain some of that performance?
  • The Administration and Frontend classes still have require statements in the boot and installer. I can't quite figure out why this is required just yet, but removing these statements and put the classes into the classmap cause some strange things to happen (frontend thinks it's the backend which breaks Members) Fixed.
  • Is this truly backwards compatible? Dropping it into some old installs it looks that way?
  • I've noticed we are pretty bad at including multiple class definitions in the one file. Something to be aware of when we rearrange the structure.
  • We have heaps of global constants. Some should be class constants. This was fun to discover as we currently have constants be defined at the bottom of certain class files instead of all in defines.php.
  • Is this even worth pulling in? Should we be using something else? If so, can you help?
@designermonkey

This comment has been minimized.

Show comment
Hide comment
@designermonkey

designermonkey Sep 6, 2014

Member

Have a look at symphony-psr on my fork, it has complete PSR-0 autoloading (remember helping me out?) The only issue was Extensions, and backwards compatibility.

Autoloading masks one of the worst things in our codebase, Symphony's classes are highly coupled and it's very difficult to use (and test) them in isolation.

We can after autoloading, begin to standardise these classes, and use __callStatic() to migrate slowly over to a non-static build. I have played with this a few times, and can work with you on it.

Member

designermonkey commented Sep 6, 2014

Have a look at symphony-psr on my fork, it has complete PSR-0 autoloading (remember helping me out?) The only issue was Extensions, and backwards compatibility.

Autoloading masks one of the worst things in our codebase, Symphony's classes are highly coupled and it's very difficult to use (and test) them in isolation.

We can after autoloading, begin to standardise these classes, and use __callStatic() to migrate slowly over to a non-static build. I have played with this a few times, and can work with you on it.

@jensscherbl

This comment has been minimized.

Show comment
Hide comment
@jensscherbl
Member

jensscherbl commented Sep 6, 2014

+1

1 similar comment
@nitriques

This comment has been minimized.

Show comment
Hide comment
@nitriques
Member

nitriques commented Sep 8, 2014

+1

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Sep 22, 2014

Member

I'll push a rebased version of this shortly, would anyone be able to help test? I'd like to know if it's backwards compatible or not. Initial tests say yes!

Member

brendo commented Sep 22, 2014

I'll push a rebased version of this shortly, would anyone be able to help test? I'd like to know if it's backwards compatible or not. Initial tests say yes!

@jensscherbl

This comment has been minimized.

Show comment
Hide comment
@jensscherbl

jensscherbl Sep 22, 2014

Member

would anyone be able to help test?

Let me know when it's ready, have to update an old project anyway, also currently working on a new one.

Member

jensscherbl commented Sep 22, 2014

would anyone be able to help test?

Let me know when it's ready, have to update an old project anyway, also currently working on a new one.

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Sep 29, 2014

Member

@jensscherbl The autoload branch is rebased with integration

@designermonkey That'd be great. I'm wondering if we can push this classmap into a composer file as well?

Member

brendo commented Sep 29, 2014

@jensscherbl The autoload branch is rebased with integration

@designermonkey That'd be great. I'm wondering if we can push this classmap into a composer file as well?

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Sep 29, 2014

Member

I was able to create a composer file for autoloading with classmap and files... only problem was that composer included the Administration and Frontend classes which causes Symphony to loop out (still trying to figure this out, appears to be in conjunction with Members). If we can exclude those classes from the classmap, then this appears to work just fine:

"autoload": {
  "classmap": ["symphony/lib", "symphony/template"],
  "files": [
    "symphony/lib/boot/func.utilities.php",
    "symphony/lib/boot/defines.php",
    "symphony/lib/toolkit/util.validators.php"
  ]
},

The performance of the Composer autoload was identical to the autoloader implemented on the autoload branch, so no dramas there!

Member

brendo commented Sep 29, 2014

I was able to create a composer file for autoloading with classmap and files... only problem was that composer included the Administration and Frontend classes which causes Symphony to loop out (still trying to figure this out, appears to be in conjunction with Members). If we can exclude those classes from the classmap, then this appears to work just fine:

"autoload": {
  "classmap": ["symphony/lib", "symphony/template"],
  "files": [
    "symphony/lib/boot/func.utilities.php",
    "symphony/lib/boot/defines.php",
    "symphony/lib/toolkit/util.validators.php"
  ]
},

The performance of the Composer autoload was identical to the autoloader implemented on the autoload branch, so no dramas there!

@bzerangue

This comment has been minimized.

Show comment
Hide comment
@bzerangue

bzerangue commented Oct 4, 2014

+1

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 5, 2014

Member

Ok everyone, check the autoload branch now. Full autoloading, including a composer file. If someone installs with composer, we'll use that autoload, otherwise we'll fallback and use the autoloader provided by Symphony.

I would like this for 2.5.2, but am happy to cut integration as 2.5.2 and make this a 2.6.0 if people would prefer.

Member

brendo commented Oct 5, 2014

Ok everyone, check the autoload branch now. Full autoloading, including a composer file. If someone installs with composer, we'll use that autoload, otherwise we'll fallback and use the autoloader provided by Symphony.

I would like this for 2.5.2, but am happy to cut integration as 2.5.2 and make this a 2.6.0 if people would prefer.

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 5, 2014

Member

Hmmm, I get this error:

Fatal error: Class 'Symphony' not found in /var/www/snake/symphony/lib/boot/bundle.php on line 22

Member

michael-e commented Oct 5, 2014

Hmmm, I get this error:

Fatal error: Class 'Symphony' not found in /var/www/snake/symphony/lib/boot/bundle.php on line 22

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 5, 2014

Member

Assuming this is just a fresh checkout of autoload? On PHP5.4+?

Member

brendo commented Oct 5, 2014

Assuming this is just a fresh checkout of autoload? On PHP5.4+?

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 5, 2014

Member

Yep, I just checked out autoload and synced the files (to a server with PHP 5.4).

Member

michael-e commented Oct 5, 2014

Yep, I just checked out autoload and synced the files (to a server with PHP 5.4).

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 5, 2014

Member

Was composer used to generate an autoload file? Is there any extensions in that build? I can't get that error to reproduce in my environment.

Member

brendo commented Oct 5, 2014

Was composer used to generate an autoload file? Is there any extensions in that build? I can't get that error to reproduce in my environment.

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 5, 2014

Member

No, I have no idea how to generate an autoload file, nor have I ever worked with composer. :-) As I said, I just copied the files 'cause you said "test it".

Yes, there are some extensions, but not many.

Member

michael-e commented Oct 5, 2014

No, I have no idea how to generate an autoload file, nor have I ever worked with composer. :-) As I said, I just copied the files 'cause you said "test it".

Yes, there are some extensions, but not many.

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 5, 2014

Member

No that's ok, I've got one install with the composer generated file, and one without. One install has 30+ extensions, the other has none.

The error is pretty much stating that this block hasn't worked at all, because the Symphony class is definitely included in the autoloader.

Member

brendo commented Oct 5, 2014

No that's ok, I've got one install with the composer generated file, and one without. One install has 30+ extensions, the other has none.

The error is pretty much stating that this block hasn't worked at all, because the Symphony class is definitely included in the autoloader.

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 5, 2014

Member

Strange, that doesn't look like it won't work. Maybe it's an extension? I don't have a clean install to try at the moment.

Member

michael-e commented Oct 5, 2014

Strange, that doesn't look like it won't work. Maybe it's an extension? I don't have a clean install to try at the moment.

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 5, 2014

Member

Is this a fresh install? The block where your error is originating should only be called if CONFIG doesn't exist. CONFIG is defined here and this file is included by the autoloader.

Something isn't right. Could you double check the permissions?

Member

brendo commented Oct 5, 2014

Is this a fresh install? The block where your error is originating should only be called if CONFIG doesn't exist. CONFIG is defined here and this file is included by the autoloader.

Something isn't right. Could you double check the permissions?

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 5, 2014

Member

That install is a work in progress, and it has been running fine all the time. Which permissions should I check? (The config file is definitely readable.)

Member

michael-e commented Oct 5, 2014

That install is a work in progress, and it has been running fine all the time. Which permissions should I check? (The config file is definitely readable.)

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 5, 2014

Member

Could you please check the symphony/lib/boot/autoload file exists and is readable?

Member

brendo commented Oct 5, 2014

Could you please check the symphony/lib/boot/autoload file exists and is readable?

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 5, 2014

Member

Yes it exists, and it has 0644 permissions, so everybody can read it.

Member

michael-e commented Oct 5, 2014

Yes it exists, and it has 0644 permissions, so everybody can read it.

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 5, 2014

Member

If you drop var_dump(file_exists(CONFIG), CONFIG, class_exists('SymphonyLoader'));exit; here, what do you get?

Member

brendo commented Oct 5, 2014

If you drop var_dump(file_exists(CONFIG), CONFIG, class_exists('SymphonyLoader'));exit; here, what do you get?

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 5, 2014

Member

Sorry, I have wasted your time. My syncing script pushed the symphony folder just fine, but forgot about the index file. I am really sorry.

Should I run the autoloader branch for a while and see how it goes?

Member

michael-e commented Oct 5, 2014

Sorry, I have wasted your time. My syncing script pushed the symphony folder just fine, but forgot about the index file. I am really sorry.

Should I run the autoloader branch for a while and see how it goes?

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 5, 2014

Member

A first impression: I have some API pages which are supposed be fast, but with the autoload branch they are approximately 0,02 to 0,03 seconds slower than with the integration branch. Or is it the Symphony debugger fooling me?

Member

michael-e commented Oct 5, 2014

A first impression: I have some API pages which are supposed be fast, but with the autoload branch they are approximately 0,02 to 0,03 seconds slower than with the integration branch. Or is it the Symphony debugger fooling me?

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 5, 2014

Member

No worries :)

A first impression: I have some API pages which are supposed be fast, but with the autoload branch they are approximately 0,02 to 0,03 seconds slower than with the integration branch. Or is it the Symphony debugger fooling me?

Yeah, I mentioned that in the first post. The convenience and scalability of autoloading comes at a cost unfortunately:

Using the classmap autoloader appears to make Symphony boot slower by about .0100s. The memory usage doubles, although the number of classes loaded for me was reduced by about 14%. Any ideas on how to regain some of that performance?

It doesn't appear to be something in our implementation of autoloading either, as the Composer version also takes a hit:

The performance of the Composer autoload was identical to the autoloader implemented on the autoload branch, so no dramas there!

I don't think there is much we can do about this. We are already using classmap's which is generally the fastest autoload implementation around.

Member

brendo commented Oct 5, 2014

No worries :)

A first impression: I have some API pages which are supposed be fast, but with the autoload branch they are approximately 0,02 to 0,03 seconds slower than with the integration branch. Or is it the Symphony debugger fooling me?

Yeah, I mentioned that in the first post. The convenience and scalability of autoloading comes at a cost unfortunately:

Using the classmap autoloader appears to make Symphony boot slower by about .0100s. The memory usage doubles, although the number of classes loaded for me was reduced by about 14%. Any ideas on how to regain some of that performance?

It doesn't appear to be something in our implementation of autoloading either, as the Composer version also takes a hit:

The performance of the Composer autoload was identical to the autoloader implemented on the autoload branch, so no dramas there!

I don't think there is much we can do about this. We are already using classmap's which is generally the fastest autoload implementation around.

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 5, 2014

Member

Interestingly, on a fresh install, no extensions, the autoload branch comes out on top on my local machine. This is running PHP 5.5.16 with XDebug on.

screen shot 2014-10-06 at 9 11 56 am
screen shot 2014-10-06 at 9 14 37 am

Member

brendo commented Oct 5, 2014

Interestingly, on a fresh install, no extensions, the autoload branch comes out on top on my local machine. This is running PHP 5.5.16 with XDebug on.

screen shot 2014-10-06 at 9 11 56 am
screen shot 2014-10-06 at 9 14 37 am

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 6, 2014

Member

I can't access events in the backend anymore, and get the following error:

bildschirmfoto 2014-10-06 um 14 40 34

Member

michael-e commented Oct 6, 2014

I can't access events in the backend anymore, and get the following error:

bildschirmfoto 2014-10-06 um 14 40 34

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 6, 2014

Member

Care to try the autoload branch again? Made a couple of changes which should resolve that :)

Member

brendo commented Oct 6, 2014

Care to try the autoload branch again? Made a couple of changes which should resolve that :)

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 7, 2014

Member

OK, running autoload branch again. Seems to run fine at first sight, but I will keep it running for a while.

Member

michael-e commented Oct 7, 2014

OK, running autoload branch again. Seems to run fine at first sight, but I will keep it running for a while.

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 12, 2014

Member

Include all required Symphony classes (by reverse-engineering dependencies)? Or can I include the Symphony autoloading mechanism, somehow?

If you're extension is being used in the Symphony context (backend page, an event, or a datasource), then autoloading is likely to already be taken care of for you as the autoloader is included in the index.php file.

If you are interacting directly with a script inside one of your extensions that totally bypasses the index.php file, then you can include autoloader exactly how the index.php file does. If you do not wish to use composer at all, that is 100% fine. The first condition will fail and you will get the Symphony autoloader loaded instead.

Member

brendo commented Oct 12, 2014

Include all required Symphony classes (by reverse-engineering dependencies)? Or can I include the Symphony autoloading mechanism, somehow?

If you're extension is being used in the Symphony context (backend page, an event, or a datasource), then autoloading is likely to already be taken care of for you as the autoloader is included in the index.php file.

If you are interacting directly with a script inside one of your extensions that totally bypasses the index.php file, then you can include autoloader exactly how the index.php file does. If you do not wish to use composer at all, that is 100% fine. The first condition will fail and you will get the Symphony autoloader loaded instead.

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 12, 2014

Member

Thanks, I will try that! (All for the sake of testing the autoload branch, and preparing some extensions for the "break" – indeed this might break any extensions that do "background stuff" with Symphony objects, e.g. the Email Newsletter Manager.)

Member

michael-e commented Oct 12, 2014

Thanks, I will try that! (All for the sake of testing the autoload branch, and preparing some extensions for the "break" – indeed this might break any extensions that do "background stuff" with Symphony objects, e.g. the Email Newsletter Manager.)

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 12, 2014

Member

Doesn't work either. Some of the extension's (background) functions simply die (silently, really). I am lost here, and I should better call for help (@creativedutchmen).

Member

michael-e commented Oct 12, 2014

Doesn't work either. Some of the extension's (background) functions simply die (silently, really). I am lost here, and I should better call for help (@creativedutchmen).

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 12, 2014

Member

I can help out too, how can I reproduce what you are seeing?

Member

brendo commented Oct 12, 2014

I can help out too, how can I reproduce what you are seeing?

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 13, 2014

Member

Wow, that is a bit difficult. It's an (un-released, private) extension that cares for Elasticsearch mappings and indexing. For background workers, it requires Redis on the server. And of course it requires an Elasticsearch connection. I think debugging would be simpler for @creativedutchmen (because he wrote the extension). If we don't hear from him, the best chance I see is to give you SSH/SFTP access to the development system.

@creativedutchmen: Maybe you will have valuable ideas "out-of-the-box"? I see failed jobs in the Redis queue, and it's especially rebuilding the Mapping that fails. Indexing seems to work. I included Symphony's autoload logic as proposed by @brendo in the extension's symphony.worker.php file, but that didn't help.

Member

michael-e commented Oct 13, 2014

Wow, that is a bit difficult. It's an (un-released, private) extension that cares for Elasticsearch mappings and indexing. For background workers, it requires Redis on the server. And of course it requires an Elasticsearch connection. I think debugging would be simpler for @creativedutchmen (because he wrote the extension). If we don't hear from him, the best chance I see is to give you SSH/SFTP access to the development system.

@creativedutchmen: Maybe you will have valuable ideas "out-of-the-box"? I see failed jobs in the Redis queue, and it's especially rebuilding the Mapping that fails. Indexing seems to work. I included Symphony's autoload logic as proposed by @brendo in the extension's symphony.worker.php file, but that didn't help.

@creativedutchmen

This comment has been minimized.

Show comment
Hide comment
@creativedutchmen

creativedutchmen Oct 13, 2014

Member

@michael-e I have no ideas out of the box, but I have time to look at this maybe later today or tomorrow.

Member

creativedutchmen commented Oct 13, 2014

@michael-e I have no ideas out of the box, but I have time to look at this maybe later today or tomorrow.

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 13, 2014

Member

Sounds great. Drop me a line if you need access to my dev server.

Member

michael-e commented Oct 13, 2014

Sounds great. Drop me a line if you need access to my dev server.

@nitriques

This comment has been minimized.

Show comment
Hide comment
@nitriques

nitriques Oct 30, 2014

Member

Just a quick side question here: should extensions developers be expected to publish their project on there https://packagist.org ? If so, I make the move (never tried composer yet)

I've been poking around with node.js a lot for the last 2 years and I must say that relying on lots of module is risky. Please pick them wisely, research on them and make sure they are dependable.

Member

nitriques commented Oct 30, 2014

Just a quick side question here: should extensions developers be expected to publish their project on there https://packagist.org ? If so, I make the move (never tried composer yet)

I've been poking around with node.js a lot for the last 2 years and I must say that relying on lots of module is risky. Please pick them wisely, research on them and make sure they are dependable.

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 30, 2014

Member

I've been poking around with node.js a lot for the last 2 years and I must say that relying on lots of module is risky. Please pick them wisely, research on them and make sure they are dependable.

Thanks! (See my moaning above).

Member

michael-e commented Oct 30, 2014

I've been poking around with node.js a lot for the last 2 years and I must say that relying on lots of module is risky. Please pick them wisely, research on them and make sure they are dependable.

Thanks! (See my moaning above).

@nitriques

This comment has been minimized.

Show comment
Hide comment
@nitriques

nitriques Oct 30, 2014

Member

The older I get, the more I love simple things

Same here :D

Member

nitriques commented Oct 30, 2014

The older I get, the more I love simple things

Same here :D

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 30, 2014

Member

Nobody who is around here is as old as I am. I am the nerd-grandpa. :-))

Member

michael-e commented Oct 30, 2014

Nobody who is around here is as old as I am. I am the nerd-grandpa. :-))

@nitriques

This comment has been minimized.

Show comment
Hide comment
@nitriques

nitriques Oct 30, 2014

Member

Nobody who is around here is as old as I am. I am the nerd-grandpa.

LOL. But still, the 28 years old me loves simplier things then the 21 years old me 😄

Member

nitriques commented Oct 30, 2014

Nobody who is around here is as old as I am. I am the nerd-grandpa.

LOL. But still, the 28 years old me loves simplier things then the 21 years old me 😄

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 30, 2014

Member

So try and imagine how it feels when you are 50!

Member

michael-e commented Oct 30, 2014

So try and imagine how it feels when you are 50!

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 30, 2014

Member

But, that is off-topic. And secret, of course! Still I want to be taken serious.

Member

michael-e commented Oct 30, 2014

But, that is off-topic. And secret, of course! Still I want to be taken serious.

@nitriques

This comment has been minimized.

Show comment
Hide comment
@nitriques

nitriques Oct 30, 2014

Member

No worries!

Member

nitriques commented Oct 30, 2014

No worries!

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Oct 30, 2014

Member

:-)

Member

michael-e commented Oct 30, 2014

:-)

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 30, 2014

Member

Relax guys, dependencies will only be introduced where necessary. Things like Monolog are well respected and mature components (it has over 7.2 million installs).

Extension developers are not expected to make their packages available via packagist. For now Composer is being looked at for core components only, not as a means to load extensions (although that's a pretty nice idea too!)

Member

brendo commented Oct 30, 2014

Relax guys, dependencies will only be introduced where necessary. Things like Monolog are well respected and mature components (it has over 7.2 million installs).

Extension developers are not expected to make their packages available via packagist. For now Composer is being looked at for core components only, not as a means to load extensions (although that's a pretty nice idea too!)

@nitriques

This comment has been minimized.

Show comment
Hide comment
@nitriques

nitriques Oct 31, 2014

Member

Relax guys, dependencies will only be introduced where necessary.

I am always relax 😄 I just wanted to share my experience with package management (npm in my case)

For now Composer is being looked at for core components only, not as a means to load extensions (although that's a pretty nice idea too!)

Ok great !

Member

nitriques commented Oct 31, 2014

Relax guys, dependencies will only be introduced where necessary.

I am always relax 😄 I just wanted to share my experience with package management (npm in my case)

For now Composer is being looked at for core components only, not as a means to load extensions (although that's a pretty nice idea too!)

Ok great !

@jensscherbl

This comment has been minimized.

Show comment
Hide comment
@jensscherbl

jensscherbl Oct 31, 2014

Member

should extensions developers be expected to publish their project on there https://packagist.org ?

Don't think so. Composer installable packages should be usable in any context. You can't use a Symphony extension in a Laravel application for example, so extensions for a particular system should be handled separately.

Extensions should also be usable out-of-the-box, so I think it's better not to exclude the vendor folder from your repository.

Composer is meant for managing code dependencies, not for managing a specific projects extension ecosystem, imo.

Member

jensscherbl commented Oct 31, 2014

should extensions developers be expected to publish their project on there https://packagist.org ?

Don't think so. Composer installable packages should be usable in any context. You can't use a Symphony extension in a Laravel application for example, so extensions for a particular system should be handled separately.

Extensions should also be usable out-of-the-box, so I think it's better not to exclude the vendor folder from your repository.

Composer is meant for managing code dependencies, not for managing a specific projects extension ecosystem, imo.

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Oct 31, 2014

Member

That's a nice delination

Member

brendo commented Oct 31, 2014

That's a nice delination

@creativedutchmen

This comment has been minimized.

Show comment
Hide comment
@creativedutchmen

creativedutchmen Oct 31, 2014

Member

@michael-e we never looked at the problems you were having. Do you still want me to take a look, or are they solved in the meantime?

And about the dependencies: I completely agree with everything that's been said. Dependencies should be avoided, and so should reinventing the wheel, it's about the balance.

Member

creativedutchmen commented Oct 31, 2014

@michael-e we never looked at the problems you were having. Do you still want me to take a look, or are they solved in the meantime?

And about the dependencies: I completely agree with everything that's been said. Dependencies should be avoided, and so should reinventing the wheel, it's about the balance.

@nitriques

This comment has been minimized.

Show comment
Hide comment
@nitriques

nitriques Oct 31, 2014

Member

Composer is meant for managing code dependencies, not for managing a specific projects extension ecosystem, imo.

Understood, thanks @jensscherbl

it's about the balance.

Totally !!

Member

nitriques commented Oct 31, 2014

Composer is meant for managing code dependencies, not for managing a specific projects extension ecosystem, imo.

Understood, thanks @jensscherbl

it's about the balance.

Totally !!

@brendo

This comment has been minimized.

Show comment
Hide comment
@brendo

brendo Nov 5, 2014

Member

This has been merged into integration. Please create new tickets if you encounter any errors.

Member

brendo commented Nov 5, 2014

This has been merged into integration. Please create new tickets if you encounter any errors.

@brendo brendo closed this Nov 5, 2014

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Nov 5, 2014

Member

@creativedutchmen: I will have to try again, next week or so. I would be glad if you could help if I encounter the same problems again!

Member

michael-e commented Nov 5, 2014

@creativedutchmen: I will have to try again, next week or so. I would be glad if you could help if I encounter the same problems again!

@creativedutchmen

This comment has been minimized.

Show comment
Hide comment
@creativedutchmen

creativedutchmen Nov 5, 2014

Member

Next week sounds good to me!

On Wed, Nov 5, 2014 at 10:27 AM, michael-e notifications@github.com
wrote:

@creativedutchmen: I will have to try again, next week or so. I would be glad if you could help if I encounter the same problems again!

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

Member

creativedutchmen commented Nov 5, 2014

Next week sounds good to me!

On Wed, Nov 5, 2014 at 10:27 AM, michael-e notifications@github.com
wrote:

@creativedutchmen: I will have to try again, next week or so. I would be glad if you could help if I encounter the same problems again!

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

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Nov 5, 2014

Member

Great! Thanks!

Member

michael-e commented Nov 5, 2014

Great! Thanks!

@michael-e

This comment has been minimized.

Show comment
Hide comment
@michael-e

michael-e Nov 13, 2014

Member

@brendo: My background process issue is solved. @creativedutchmen found the problem, which boiled down to something like "Michael doesn't know what he does". :-)

Actually the script loading the Symphony classes (which I tried to replace by Symphony's autoloader logic from index.php) ran as (resp. in) a daemon. I had completely overseen that this daemon needs to be restarted for changes to have any effect. Stupid me.

So I am back on the "bleeding edge" (i.e. integration branch) with my current development project!

Member

michael-e commented Nov 13, 2014

@brendo: My background process issue is solved. @creativedutchmen found the problem, which boiled down to something like "Michael doesn't know what he does". :-)

Actually the script loading the Symphony classes (which I tried to replace by Symphony's autoloader logic from index.php) ran as (resp. in) a daemon. I had completely overseen that this daemon needs to be restarted for changes to have any effect. Stupid me.

So I am back on the "bleeding edge" (i.e. integration branch) with my current development project!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment